16 - Separated Environments - BSC

# Topic 16: Separated Development, Testing, and Production Environments **Environment segregation** is the security practice of dividing the software lifecycle into distinct, isolated environments: **Development (Dev)**, **Testing/Staging (Test)**, and **Production (Prod)**. Implementing separated environments ensures that code failures or security breaches in one environment do not compromise the stability, confidentiality, or integrity of the live, public-facing application and its stored data. --- ## Core Separation Tiers A robust environment architecture enforces complete isolation across three tiers: ``` [Development (Dev)] [Testing/Staging (Test)] [Production (Prod)] * Developers' local devices * Quality Assurance (QA) servers * Live public app servers * Weak security controls * Moderate security controls * Maximum security controls * Synthetic dummy data * Sanitized database backups * Live, encrypted user data │ │ │ └────────────── (Network Firewall Isolations) ────────────────────┘ ``` --- ## Key Mechanisms of Segregation To protect software development practices and stored data, organizations enforce isolation in three main areas: ### 1. Network Isolation (Firewalling & VPCs) * **The Mechanism**: Dev, Test, and Prod servers are hosted in separate networks (Virtual Private Clouds - VPCs) or separate cloud accounts. * **The Protection**: Firewalls and security groups block all incoming network traffic from Dev/Test to Prod. If an attacker compromises a staging server, they cannot move laterally (pivot) into the production system. ### 2. Data Segregation (Sanitization) * **The Mechanism**: Non-production environments use synthetic data or databases that have been stripped of customer names, passwords, credit card numbers, and other PII. * **The Protection**: If a developer’s laptop or staging server is compromised, zero actual customer data is leaked. ### 3. Secret & Credential Isolation * **The Mechanism**: Each environment uses unique API keys, database connection strings, and encryption keys. * **The Protection**: Staging API keys are of no value to an attacker trying to compromise production data. Production credentials are kept in a secure manager and are injected at runtime by automated **Continuous Integration / Continuous Deployment (CI/CD)** pipelines (like GitHub Actions) without human exposure. --- ## Classification of Environment Controls | Control Type | Examples in Environment Segregation | | :--- | :--- | | **Software Controls (Technical)** | * Implementing Virtual Private Cloud (VPC) subnets and network firewalls. * Automating database sanitization scripts to strip PII before test database creation. * Deploying code via automated CI/CD build servers (e.g., GitHub Actions, Jenkins). * Restricting developer access to production cloud accounts. | | **Administrative Controls** | * Data Handling Policy (strictly prohibiting copying production databases to developer laptops). * Strict access control policies specifying who is allowed to authorize deployments to production. * Network architecture reviews. | --- ## VCE Exam Practice ### Scenario *EasyShop* develops an e-commerce platform. To save server costs, the company runs their local test server and the live customer website on the same physical server, using the same database instance with different table prefixes. A hacker exploits a vulnerability in a new, unreviewed plugin on the test server, gains root operating system access, and immediately reads all live customer transactions from the shared database. ### Questions 1. **Define** the concept of 'separated environments'. *(1 mark)* 2. **Explain** the security risk EasyShop took by combining their test and production environments on the same server. *(2 marks)* 3. **Propose and justify** two software controls EasyShop should implement to isolate their environments. *(4 marks)* --- > [!NOTE] > **Suggested Answers:** > 1. *Separated environments is the security practice of hosting development, testing, and live production application systems on isolated networks and hardware to prevent a breach or failure in one from affecting another.* > 2. *By sharing the same server and database instance, EasyShop had no physical or network isolation between environments. The risk is lateral movement: if an attacker compromises the lower-security test environment, they instantly gain administrative access to the live production server and database, compromising real customer transactions.* > 3. * *Control 1: Network & Account Isolation (VPCs)*. Host the production application on a completely separate cloud account or server network (VPC) with firewalls blocking all traffic from the test server. This prevents lateral movement. > * *Control 2: Database Sanitization & Separate Database Instances*. Deploy a completely separate database server for the testing environment that contains only mock/dummy transaction records. This ensures that even if the test database is compromised, no real customer data is exposed.*