How to secure the IT Environment of your customers?

Secure the IT Environment of your Customers

 

Introduction

 

Purpose

“Secure the IT Environment of customers” is part of Environment management, which describes the processes that is used to keep technical systems operational and facilitate new changes to the technology supporting the customer platform. Both technical and procedural mechanisms are in place to ensure that no undesired changes take effect and that quality of service remains at the highest level. This document clarifies what those mechanisms are and how they benefit the customer.

 

Securing IT Environment of your customer

Scope

The first part of “Secure the IT Environment” is the scope. The following section describes the requirements for environment management as required for the Platform. It is limited to defining the key areas of interest around enterprise environment management and the strategic approach that will be taken to ensure that technical systems are updated and maintained according to the customer’s requirements. The following key activities for environment management:

  • Manage Platform software licenses (including the provisioning of all licenses)
  • Administer operational and analytical databases
  • Ensure that all required security controls are in place for all components
  • Perform shared software components resource capacity planning in accordance with the capacity planning processes
  • Provision new shared software component capacity
  • Provide Level 2/3 support for shared software components in accordance with the incident management process
  • Plan and execute required Platform software component changes in accordance with the change and release management processes, including producing the release packages
  • Maintain Platform software component configuration information in accordance with the configuration management process
  • Proactively monitor all Platform software components in accordance with the event management and monitoring processes
  • Identify patches and required upgrades including impact assessment
  • Coordinate the schedule for and apply patches and upgrades to Platform software
  • Maintain the configuration of the shared components to meet other service providers’ needs
  • Provide technical expertise and support to service providers during design and leverage of Platform software components
  • Provide and support Platform tools (e.g., Help Desk ticketing, document repository, testing tools)
  • Provision new users and services on the shared components (e.g., when a service provider adds services you will have to update directories)
  • Enable and support disaster recovery, including providing the capability to migrate an application and data from the DR Data Center back to the primary data center with minimum manual involvement
  • Maintain all application administration shared services (code/configurations of enhanced IT operational capabilities that can be leveraged by all vendors)

Environments

The customer’s physical servers support multiple logical environments. Environments are divided into locations, categories, and tiers based on the environment’s needs. Understanding the environment helps to secure the IT environment with the necessary controls.

Environment Types

An environment’s type is based on the functionality needed. List out the following types that the project should support.

Environment Description
   
   
   

Environment Categories

Environment Category Description
   
   
   

Environment Tiers

The environments are tiered based on the overall project need of the environment. Below are the breakdowns of the environment tiers.

Tier Description
Tier 1 Production equivalent environment. The environment is built in a clustered configuration and contains live production data. It includes the Production (PRD), Disaster Recovery (DRX), Staging (STG), and User Acceptance Testing (UAT) environments.
Tier 2 Testing environment. The environment is built in a clustered configuration and contains masked data. It includes the System Integration Testing (SIT) environment.
Tier 3 Development environment. The environment is built in a single node configuration and contains no production data. It includes the Development (DEV) and Production Support (PSD) environments.

The following figure shows the migration path that allows changes to be moved from lower environments up to production. This is an important process that shows how to secure the IT environment, from Development to Production and UAT to Production.

 

Flow to secure the IT Environment

Integration Workflows

You need to fill up the following business functions and their descriptions as provided with respect to integration workflows.

Business Function Description
   
   
   
   
   
   
   
   

 

Fill the required diagram that is unique to your organization showing relationships of servers, from both a Client Portal, Worker Portal etc., showing key details like Load Balancer, reporting etc.

Instance strategy

Production Environment

The production environment (PRD01) consists of all application technology stack components (e.g., SOA, Adobe) for various applications. Each application component is supported by underlying infrastructure. These infrastructure elements, along with the related application components, comprise what is known as an instance. The production environment has several layers of application, middleware, and database technologies being used by both internal and external users.

Describe and showcase your diagram showing the different tiers: Client, Presentation, Application, Middleware and Data for both internal and external users. These are your Production Components.

 

Non-Production Environments

The non-production environments for eligibility assistance portal and customer employee portal each comprise all application technology stack components (e.g., SOA, Adobe). The technology components are shared across environments for most of the non-production environments. The current non-production environments are listed in the following table. A few examples are shown for you.

 

Non-Production Environments Description
DEV02  Development 2 Instance
STG02  Staging 2 Instance
SIT01  System Integration Test 1 Instance
   
   
   
   
   
   
   

Additionally illustrate the future state of various environments running on the portals. Use various patterns and colors to represent environments that will be added or relocated. You can name it as “Future State of Environments by Technology Stack”.

Instance Management

Instances are defined by technology stack, environment, and component. Dedicated instances within eligibility assistance portal frequently utilize shared services within customer portal. Thus, when describing communication between multiple components and technology stacks it is advisable to use the eligibility assistance portal’s stack as the initial reference point. Instances are frequently changed to introduce new functionality or correct an existing issue. Once the desired outcome is achieved then the change is promoted to higher environments for various levels of testing.

Patching process

The patching process that keeps customer environments up to date is critical to the success of environment management. Both security and functional patches are implemented to keep the environments operational.

Critical patch updates are put into place on a monthly/quarterly basis and are aligned with vendor release dates. Security patches are put into place according to any potential vulnerabilities identified by scans. The affected environments are scanned after being patched to ensure that the vulnerability was mitigated successfully.

Backup and recovery

Data Availability Requirements

To secure the IT Environment, the production environments of the Platform supported are required to be 99.99% available outside of planned maintenance windows. Maintenance windows are required to improve application or infrastructure functionality and to address defects such as security vulnerabilities that necessitate a patch. Maintenance windows should not be used to facilitate regularly scheduled backups. The overall backup strategy for production environments must allow for all relevant data and applications to be backed up while the systems are online and operational.

While non-production environments do not have the same availability requirements as production environments, non-production environments are used by multiple application systems integrators for strategic development, testing, and support. Data availability issues can potentially impact the timeline of applications system integrator deliverables. Therefore, the backup strategy for the non-production environments must be very robust to minimize impact to any of them.

Data Loss Impact

For the production environments of the Platform supported, the impact of data loss is dependent on system components. For most production system components, the impact of data loss is substantial. Therefore, the backup and restore strategy must take in to account eliminating, or at the very least minimizing, the possibility of data loss. In addition, the production environment has a disaster recovery solution in place should an event take place that results in the unavailability of data or systems.

While data loss of the non-production environments is not as critical as the production environments, the impact would still be substantial given the 24×7 development/testing/support model of multiple applications systems integrators. Therefore, the backup strategy for non-production environments must be very robust to minimize the possibility of data loss impact to any of them.

Data Recovery Model

The data recovery model must be very flexible and robust for the production environments of the Platform. Overall, the data recovery model must to be consistent across all technical and functional components of the environment so that all systems needing recovery are recovered to a consistent representation of the overall functionality. For example, in the need for recovery of a database, any application data on file systems to support the same functional need must be recovered to a point in time consistent with when the database is recovered. Inconsistencies between the two (database and file system) impact the integrity of the application systems. The data recovery model used for the production environments of the Platform supports this consistency requirement. The same flexibility and robustness of the data recovery model is also necessary for the non-production environments given the 24×7 development/testing/support model of multiple applications systems integrators. This is one way to secure the IT Environment.

Data Restoration Process

A key element to secure the IT Environment, especially for the Platform’s production environments, the need for data restoration can be identified by either the business or applications systems integrator. Once this need is identified and confirmed, the restoration process begins. This process begins with either the creation of an emergency change request (for production) or a standard change request (for non-production environments) documenting specifically what needs to be restored. The restoration requirements can range from a single file restore to the restoration of an entire environment.

Change Management Process Guide

Authored by Vijay Chander – All rights reserved – 2023

No Comments

Sorry, the comment form is closed at this time.