Contents
1. Software Staging and Release
Deploying code without processes (the wrong way to do it)
- Surprises end users
- Introduces security flaws
- Causes operational disruptions
- Increases the difficulty of rolling back flawed code
Stage 1 – Development Environment
Allows developers to develop and modify code
Stage 2 – Test Environment
Facilitates human and automated testing
Stage 3 – Staging Environment
Prepares the code for release to production in a simulated environment. Load testing occurs at this stage.
Stage 4 – Production Environment
Provides live services to end users
Important issues in these stages
- Sensitive data: this should be tightly controlled or prohibited in non-production environments. EG: use test data
- Code deployment: this should be done by someone other than a developer. EG: a release management team.
2. Software Risk Assessment and Mitigation
Risk Analysis identifies risk
Risk Mitigation reduces their likelihood and impact
Software Development Lifecycles (SLDC)
In Software Development security must be integrated from the very start. It is not something that can be added in later. Security should be integrated with the Software Development Lifecycle (SLDC). SLDCs include:
- Waterfall
- Agile
- Spiral
Security must be integrated at all stages – Design, development, testing and deployment.
Mitigate Software Risks
Some ways to mitigate software risks include:
- Perform input validation on user input
- Encrypt sensitive data so that if a database does get compromised the data is encrypted
- Enforce the principle of least privilege
- Test all code prior to deployment
Sandboxing
This is a test environment where developers can run their code without it having access to production resources. Sandboxes work hand in hand with code repositories. A developer may test a copy of code from a repository in a sandbox, then once finished testing they put it back in the repository.
3. Security Baselines and Integrity Measurement
A baseline is a minimum or a starting point used for comparisons.
Deviations: these are changes from the baseline
Integrity Management: this tracks changes made to code after deployment, noting unexpected changes
