Configuration and Change Management

2025.8

Matrak standardizes and automates configuration management through the use of automation scripts as well as documentation of all changes to production systems and networks. Automation tools such as AWS CDK and custom scripts automatically configure all Matrak systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.

Policy Statements

Matrak policy requires that:

(a) All production changes, including but not limited to software deployment, feature toggle enablement, network infrastructure changes, and access control authorization updates, must be invoked through approved change management process.

(b) Each production change must maintain complete traceability to fully document the request, including requestor, date/time of change, actions taken and results.

(c) Each production change must be fully tested prior to implementation.

(d) Each production change must include a rollback plan to back out the change in the event of failure.

(e) Each production change must include proper approval.

• Changes go through design review (performed by design team), code review (performed by engineers), and business review (performed by product manager).
• Architectural, schema, or significant product changes require CTO approval.
• Approvers must be someone other than the author/executor of the change.

Controls and Procedures

Configuration Management Processes

1. Configuration management is automated using AWS CDK and custom scripts to enforce secure configuration standards.

2. All changes to production systems are reviewed through our multi-stage approval process including design review, code review, business review, and CTO approval for significant changes to ensure they comply with business and security requirements.

3. All changes to production systems are tested before they are implemented in production.

4. Implementation of approved changes are only performed by authorized personnel.

5. Tooling is used to generate an up to date system inventory.

   • All systems are categorized and labeled by their corresponding environment, such as dev, test, and prod.
   • All systems are classified and labeled based on the data they store or process, according to Matrak data classification model.
   • The Security team maintains automation which monitors all changes to IT assets, generates inventory lists, using automatic IT assets discovery, and services provided by each cloud provider.
   • IT assets database is used to generate the diagrams and asset lists required by the Risk Assessment phase of Matrak's Risk Management procedures
   • Matrak Change Management process ensures that all asset inventory created by automation is reconciled against real changes to production systems. This process includes periodic manual audits and approvals.
   • During each change implementation, the change is reviewed and verified by the target asset owner as needed.

6. EC2 instances in AWS are provisioned using approved Amazon Machine Images (AMIs). Docker containers are launched using approved Docker images.

7. All frontend functionality (e.g. user dashboards and portals) is separated from backend (e.g. database and app servers) systems by being deployed on separate servers or containers.

8. All software and systems are required to complete full-scale testing before being promoted to production.

9. All code changes are reviewed to assure software code quality, while in development, to proactively detect potential security issues using pull-requests and static code analysis tools. More details can be found in the Software Release / Code Promotion section.

Production Systems Provisioning

1. Before provisioning any systems, a request must be created and approved through our change management process using Jira and Productboard.

   • Access to these systems requires authenticated users.
   • Access is granted following the procedures covered in the Access Establishment and Modification section.

2. Provisioning requests must be approved through our multi-stage approval process before any new system can be provisioned, unless a pre-approved automation process is followed.

3. Once provisioning has been approved, the implementer must configure the new system according to the standard baseline chosen for the system's role.

4. If the system will be used to store sensitive information, the implementer must ensure the volume containing this sensitive data is encrypted.

5. Sensitive data in motion must always be encrypted.

6. A security analysis is conducted once the system has been provisioned. This can be achieved either via automated configuration/vulnerability scans or manual inspection by the security team. Verifications include, but is not limited to:

   • Removal of default users used during provisioning.
   • Network configuration for system.
   • Data volume encryption settings.
   • Intrusion detection and virus scanning software installed.

7. The new system is fully promoted into production upon successful verification against corresponding Matrak standards and change request approvals.

User Endpoint Security Controls and Configuration

1. Employee laptops, including Windows, Mac, and Linux systems, are configured by the device owner following company security guidelines.

2. Security controls are managed by employees on their devices according to company policies, including:

   • Unique user accounts and strong passwords
   • Security software as appropriate for the device
   • Regular security updates

3. Security configurations on end-user systems are managed by employees with periodic guidance and review as needed.

Server Hardening Guidelines and Processes

1. Linux System Hardening: Linux systems have their baseline security configuration applied via automation tools. These tools cover:

   • Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
   • Stopping and disabling any unnecessary OS services.
   • Configuring session inactivity timeouts for SSH sessions.
   • Configuring disk volumes with appropriate encryption where supported, including ensuring that encryption keys are protected from unauthorized access.
   • Configuring audit logging as described in the Auditing Policy section.

2. Windows System Hardening: Windows systems have their baseline security configuration applied via automation scripts. These baseline settings cover:

   • Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
   • Stopping and disabling any unnecessary OS services.
   • Configuring session inactivity timeouts.
   • Configuring transport encryption according to security requirements.
   • Configuring audit logging as described in the Auditing Policy section.

3. Any additional configuration changes applied to hardened systems must be clearly documented by the implementer and reviewed through our approval process.

Configuration and Provisioning of Management Systems

1. Provisioning management systems such as configuration management servers, remote access infrastructure, directory services, or monitoring systems follows the same procedure as provisioning a production system.

2. Critical infrastructure roles applied to new systems must be clearly documented by the implementer in the change request.

Configuration and Management of Network Controls

All network devices and controls on a sensitive network are configured such that:

• Vendor provided default configurations are modified securely, including

• default encryption keys,

• default SNMP community strings, if applicable,
• default passwords/passphrases, and

• other security-related vendor defaults, if applicable.

• Encryption keys and passwords are changed anytime anyone with knowledge of the keys or passwords leaves the company or changes positions.

• Traffic filtering (e.g. firewall rules) and inspection (e.g. Network IDS/IPS or AWS VPC flow logs) are enabled.

• An up-to-date network diagram is maintained.

In AWS, network controls are implemented using Virtual Private Clouds (VPCs) and Security Groups. The configurations are managed as code and stored in approved repos. All changes to the configuration follow the defined code review, change management and production deployment approval process.

Provisioning AWS Accounts

Infrastructure-as-Code

Matrak AWS environments and infrastructure are managed as code. Provisioning is accomplished using a set of automation scripts and CloudFormation code. Each new environment is created as a sub-account connected to Matrak-master. The creation and provisioning of a new account follows the instructions documented in the Bootstrap a new AWS environment page of the development wiki.

Automated change management for deploys to AWS

The Matrak Continuous Delivery Pipeline integrates with our change management process using GitHub Actions for build and deployment automation.

Patch Management Procedures

Local Systems

Matrak uses automated tooling to ensure systems are up-to-date with the latest security patches.

• On local Linux and Windows systems, the unattended-upgrades tool is used to apply security patches in phases.

  • High Risk security patches are automatically applied as they are released
  • Monthly system patching for regular applications are applied as needed.
  • Snapshotting of a system will take place before an update is applied.
  • Once the update is deemed stable the snapshot will be removed.
  • In case of failure of the update the snapshot will be rolled back.
  • If the staging systems function properly after the two-week testing period, the security team will promote that snapshot into the mirror used by all production systems. These patches will be applied to all production systems during the next nightly patch run.
  • The patching process may be expedited by the Security team
  • On Windows systems, the baseline Group Policy setting configures Windows Update to implement the patching policy.

Cloud Resources

Matrak follows a "cattle-vs-pets" methodology to keep the resources in the cloud environments immutable and up-to-date with security patches.

• AWS Elastic Container Service (ECS) is used to dynamically manage container resources based on demand.

• Engineering team builds security-approved AMI from the latest AWS optimized Amazon Machine Image (AMI) to include required security agent.

• The security agents installed on the security-approved AMIs continuously scan for and report new vulnerabilities.

• Custom AMIs are rebuilt as needed to include security patches and updates.

User Endpoints

Matrak encourages regular security updates for all user endpoints, including laptops and workstations. Users are responsible for maintaining security updates on their devices according to company policies.

Production Deploy / Code Promotion Processes

All production changes follow our multi-stage approval process as defined in the policy statements:

• Changes go through design review (performed by design team), code review (performed by engineers), and business review (performed by product manager).
• Architectural, schema, or significant product changes require CTO approval.
• Approvers must be someone other than the author/executor of the change.
• All changes must be fully tested prior to implementation and include a rollback plan.

For production deployments, a Change Request (CR) is created in our Change Management System using the Production Change Management (PRODCM) Jira project.

• Each PRODCM ticket requires the following information at a minimum:

  • Summary of the change
  • Component(s) impacted
  • Justification
  • Rollback plan

• Additional details are required for a code deploy, including:

  • Build job name
  • Build ID and/or number
  • Deploy action (e.g. plan, apply)
  • Deploy branch (e.g. master)
  • Target environment
  • Links to pull requests and/or Jira issues
  • Security scan status and results

Emergency Change

In the event of an emergency, the person or team on call is notified. This may include a combination or Development, IT, and Security.

If an emergency change must be made, such as patching of a zero-day security vulnerability or recovering from a system downtime, and that the standard change management process cannot be followed due to time constraint or personnel availability or other unforeseen issues, the change can be made by:

• Notification and Approval: The CTO must be notified and must approve the emergency change prior to implementation. Notification should be by email, Slack, or phone call. Depending on the nature of the emergency, the CTO may choose to inform members of the executive team.

• Access and Execution: Manually access of the production system or manual deploy of software, using one of the following access mechanisms as defined in Access Control policy and procedures:

  1. Support/Troubleshooting access
  2. Root account or root user access
  3. Local system access (for on-premise environment)

• Post-emergency Documentation: An Incident Report must be created within 24 hours following the emergency change. The report must contain all details related to the change, including:

  • Reason for emergency change
  • Method of emergency access used
  • Steps and details of the change that was made
  • CTO approval documentation
  • Follow-up actions required

• Prevention and Improvement: The change must be fully reviewed by Security and Engineering together with the person/team responsible for the change. Any process improvement and/or preventative measures should be documented and an implementation plan should be developed.