Deployment Environments
A deployment environments is a general term that describes a relatively isolated information systems environment that is dedicated to the requirements and hosting of particular classes of applications and services. While the specific types of deployment environments can vary between organizations, the standard deployment environments are known as Development, Integration, Test, Staging, and Production. Each standard deployment has its level of trust and security. The level of trust is at its lowest starting with the development environment and progresses to the highest level of trust in the production environment. Access control, services, tools, and source code are aligned with each production environment.
Software changes are made in the development environment. This environment is typically a developer’s workstation. As such, this environment has the lowest level of trust, with the trust being only that which can be placed on an individual developer.
Typically, the development environment is logically limited to its version control branch. The developer works on a copy of this branch. Formal code reviews may be conducted on the code associated with this environment. They typically have control over their environment with the ability to download and run the software. The developer is responsible for code quality, safety, security, and integration at this level. This freedom makes this environment untrusted.
The integration environment is one where the collective developers’ changes are combined and compiled together. The integration environment is used to verify code quality, safety, security, and integration. This environment is one where the code is evaluated against a battery of tests including unit testing, integration tests, functional tests, and often security code scans, as well as other code quality measures. Any code quality failures in the integration deployment environment usually are and should be treated as a sign to the development teams to “stop and fix” the problem(s) before committing any more code to version control.
The test deployment environment is the next stage of quality control where various automated quality measures and tests are complemented by human-directed quality activities. This environment is also the next step up in scope and size of data complexity and assessment rigor. Data sets mirror production, but as they are sanitized for test purposes, they are used to simulate a real-world (production) environment. Load and performance testing is conducted at this level.
The staging environment is used to test all installation, configuration, and migration scripts and procedures before they are applied to the production environment. This evaluation verifies the reliability of these factors before promotion to production.
The production environment is when the software goes live. This is where the actual value of the collective software development activities is realized. This is the most protected environment and as such is the most trusted environment. Access to the production environment should be strictly on a needful, least privileged basis and should be strongly enforced. Furthermore, data held in the production environment can be highly sensitive or valuable, or have classification restrictions, and should be protected as such.
Secure Code Promotion
After code has been written by the developers and is complete enough to be tested, it should be tested in a different software environment than the one in which it was developed. The code should be delivered to the test environment in a form similar to how it would be deployed to production. The control over the test environment should be more intensive. Advancing code from a lower environment to a higher environment like this is known as code promotion.
Promoting code from development to integration, integration to test, test to staging, and staging to production comes with more stringent code quality, code safety, and soft- ware security and security control environment requirements. Promoting code from one deployment environment to the next should be done only to the next immediate level up. Skipping a level, such as going from the development environment to production, is both poor form and bad security practice. Each deployment environment has a specific soft- ware quality and security control purpose. When a deployment environment is skipped over in a code promotion, critical testing and verification activities can be missed that might lead to bugs or security vulnerabilities. It also means that your development process lacks maturity.
The code promotion workflow does not have to be slow or cumbersome. Auto- mating the build, verification, quality assurance, and security testing accelerates this process. Automation such as this takes more up-front investment in standing up the workflow process automation and writing the tests, but these investments pay off by building security into the software development environment. This is also known as “shifting security left.”
Security Issues with Deployment Environments
Security control is intensified with the progression from a development environment to a production environment. This is because of the type of data used in each environment and the increasingly greater confidentiality, integrity, and availability requirements. This progression of deployment environments goes from least trusted/least secured to most trusted and most secured. As the trust and security requirements increase, so do the following control requirements: access control and privileged access control, logging, monitoring, security event management, configuration management, change management, and data protection.
These are some of the control areas that intensify with the increasing level of trust and security of the environment:
- More rigorous access control: Access control shall adhere to the least privilege model and be implemented commensurate with the requirements of the environment.
- Privileged access management: Baseline access control in higher environments is privileged to access and should be limited by least privilege. The entitlements considered privileged in lower environments is highly privileged in higher environments.
- Logging, monitoring, and security event management: Logging, monitoring, and security event management control requirements intensify in higher deployment environments. Higher environments that have significant risk exposure require security event management.
- Configuration and change management: The control over the state of the soft- ware and its environment and the process by which the state of every aspect is managed increases with the trust and security requirements of the environment to which they apply.
- Secrets management: Secrets in this context are the configuration and environment variables that are required to deploy the software and set up aspects of its environment. Some examples of secrets are database connection and credential information, services credentials, and service or application secret keys. Keeping these variables in source code is a serious security mistake because doing so could lead to a potential sensitive data Secrets should be securely held and managed outside of the source code. Many of these variables are specific to the deployment environment. As the trust and security levels of the environment increase, so do the protection requirements for these variables. These configuration and environment variables, when associated with higher deployment environments, become secrets. It is essential to the security of the deployment environments that these variables be managed as secrets. These variables must be strictly maintained by a “need to know,” least privilege access control and data protection that is commensurate with the trust and security of the environment with which they are associated.
- Encryption key management: As the security and trust levels increase by environment, so shall the encryption and key management requirement.
See FIPS 140-2, “Security Requirements for Cryptographic Modules” (https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/ Standards) and the OWASP Key Management Cheat Sheet (https://www.owasp.org/ index.php/Key_Management_Cheat_Sheet) for insights on aligning these requirements.
