Overview
Policy Statement
Change is an essential part of the modern business environment and an effective supporting IT organization has to manage the implications of any change that sets it apart from others. Whether the change is proactive to move us forwards or reactive to adapt to incidents, problems, or external events such as new legislation, it will inevitably carry an element of risk with it.
your organization automates configuration management using automation (scripts, RPA, bots). Changes to production systems and networks are always logged. your organization uses Terraform to automatically configure IT systems.
Special care is required for Production Environments. All Production changes must be fully tested, have adequate approval, and be fully recoverable with automatic rollbacks in case of failure.
Scope
Changes to the your organization information technology environment that may cause:
- Infrastructure elements:
- A service to be down, or degraded;
- A change in the functionality of a service, or introduce a new service;
- An infrastructure configuration change.
- Software elements:
- Includes design and code changes related to service epics and user stories;
- Defect fixes originating from testing/quality assurance;
- Adhoc requirements changes.
Objectives
The objectives of the change management process are to:
- Manage the assessment and implementation of changes to the IT environment following the business requirements and risk appetite of the organization;
- Ensure that the Configuration Management Systems (CMS) remains up to date in the face of frequent and varying changes;
- Keep accurate records of changes made and the configuration items affected by them, for use in other processes such as incident and problem management;
- Provide benefit to the business by delivering desirable change whilst preventing undesirable change.
Procedures
Procedures and mapped controls
Configuration Management Processes
- No systems are deployed into your organization Production environments without the approval of the CTO;
- Production environment changes are reviewed and approved by Security Team before being deployed to production;
- Production environment changes are tested before being deployed in production;
- Automation is part of the asset management strategy and creates an updated inventory;
- Environments and their underlying assets are labeled for production, development, or testing;
- Data Classification labels must be attached to each asset;
- During each change implementation, the change is reviewed and verified by the asset owner;
- your organization uses a single source of truth for time-synchronization and uses a pre-approved NTP server. Modifying time data on systems is restricted;
- All laptops, workstations, mobile devices, and servers must be hardened based on best-practices, such as:
- Windows systems use hardware encryption such as BitLocker
- Linux systems use only hardened and approved distributions
- GCP VMs are provisioned using only hardened and approved images
- AWS EC2 instances are provisioned using only hardened and approved images (AMI)
- Mobile Devices are checked to ensure proper patching and up-to-date system updates. your organization uses:
- *AirWatch from VMWare- for MDM (iOS and Android)
- *Microsoft Intune- for Windows systems
- *Jamf- for macOS systems
- Docker Containers are launched using only Docker images which have been signed and validated by the Security Team
- Docker images are secured in the CI/CD pipelines and stored in the Container Registry. your organization uses *Anchore- and *Clair- for scanning and validating Docker images.
Promoting code to Production
your organization uses a CMS to track change requests. Changes and approvals are managed following these steps:
- Approval is required for each change request. your organization's approver is the CTO;
- Change requests must be written with the following details:
- Description
- Change reason
- Affected systems, applications, and data
- Version (for code, image, deployment, etc.)
- Security scan status and results
- Production environment, such as
gcp-companyName-prod
More info can be found in the Software Release and Deployment Management Policy
Infrastructure and Network Change
- Default configurations are to be changed for hardening reasons;
- Default passwords/passphrases;
- Default encryption keys must be changed;
- Passwords and encryption keys must be automatically rotated on a regular basis and changed if they are known by employees or 3rd Parties that cease to work with your organization;
- Firewall rules, traffic monitoring, network flow must be enabled and preserved for auditing.
Configurations are stored and versioned using Infrastructure as Code (IaC), and any changes to this configuration must follow the approval steps before being considered suitable as a bootstrap project for the production infrastructure.
Endpoint Configuration Change
-
Laptops, workstations, and mobile devices are configured by IT or by the device owner. your organization also uses an automatic system (VMWare AirWatch or Microsoft Intune) to manage configuration and handle changes to these endpoints. Each endpoint must have:
- Personal or Company label - important for management and remote triggers such as Data Wiping or Lost Mode activation
- Disk encryption - specific for that operating system
- Approved NTP servers
- Strong passwords based on your organization Password Management Policy
- Automatic system locking after 5 mins of inactivity
- Auto-update (at least for security patches)
-
Automated compliance checks are performed regularly to ensure the proper configuration of these endpoints.
Monitoring and Auditing
Configuration auditing has the objective of detecting and alerting on deviations from standards, misconfigurations, or anything suspicious regarding production environment changes.
Roles
Change Requestor
- Raises the request for change
- Documents the request and indicates the service and/or systems impacted by the change
- Primarily part of the IT or development teams, but project managers can also enter requests on behalf of members of their project teams
Change Manager (CM)
- Manages the change request process
- Facilitates review and triage of change requests, and assessment of risk level
- Determine the need for additional information
- Approval to move into the planning stage
Change Advisory Board (CAB)
- Meets daily
- Review and triage of change requests, and assessment of risk level
- Determine the need for additional information
- Review and authorize Standard change requests
- Review and authorize Normal change requests with a higher level of risk or impact
- Review and authorize Emergency change requests, as needed
- Approval of request to move into the planning stage
- Approval of request to move into the implementation stage
Change implementation team
- Resources that implement changes
- Update the request and document the work completed as part of the request
Type of Changes
Standard
- Routine changes, risks are known, and minimal impact
- Change advisory board reviews and approves, or rejects
Normal
- Require change process approval due to higher risk or impact
- Non-standard and non-emergency changes that require change management review
- Change requests are reviewed by the change advisory board (CAB) and approved or rejected (e.g. require more information)
Emergency
- Unexpected issues that need to be addressed immediately. E.g. system down, security threat, etc.
- Change advisory board is notified of risk and impact and meets, as needed, to review and advise the implementation teams
- Change advisory board works with the implementation and development teams, as needed
Major
- Requires the removal or decommissioning of a service
- Involves the transfer of service from your organization to another business or a third-party
- Creates a new service
- Requires more than 5 days of IT resource
Examples of changes in scope
The following are examples of recently implemented or planned changes that will in the future require a change request to be raised and approved:
- Changes to AWS infrastructure
- Changes to interfaces that include parameters that get passed to/from an API
- Changes to database schema (E.g.: Physical database changes including updates of columns etc.)
- Changes to the analytics engine
- Changes that involve customer journeys/customer experience through the UI
- Changes to the UI (E.g.: Graph Database changes)
Examples of changes out of scope
The following are examples of tasks that are considered to be service requests or administrative tasks and so will not require a change request to be raised and approved:
- Creating a new user
- Changing a user's password (password reset)
- Mapping a drive for a user
- Installing individual new PCs
- Upgrading memory in an individual PC
- Installing software on a user's desktop
Change Management Tools
Several key software tools underpin an effective change management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However, the main types of tools that play a significant part in the process within your organization are as follows.
Change Management System
The change management system is a workflow system that allows the logging of RFCs directly into the process via a web interface and a desktop client. Changes are then managed and directed according to the defined process, under the control of the change manager. Tasks can be assigned to individual users for change assessment and authorization and later on for change building, testing and implementation.
Results of all reviews can be recorded as notes within the system, along with pre-defined information at each stage of the process. Supporting information such as test and back-out plans may be attached to change records and accessed by those involved in the process for that specific change.
Configuration Management Database
The configuration management system provides the capability to link changes with the configuration items they affect, building up a change history for CIs such as servers, databases, and applications. This is useful in incident management where a particular incident may be traced back to a change made at an earlier date.
The status and version of CIs may be updated as the change management process progresses so that an accurate picture of the organization's infrastructure is maintained at all times, even in the face of frequent change.
Release Management System – CI/CD + Container Registry
The Release Management system within your organization provides automated build capabilities and (Docker) Container Registry – the storage place for deployables that are later deployed into infrastructure dynamically as containers.
The Container Registry also maintains limited information on versioning of deployable which could be reverted at a later point in time if needed by rolling back changes in a Kubernetes Cluster.
Query logic
These are the stored checks tied to this policy.
No stored query bodies are attached to this entry.
