Identify and Apply Security Controls in Development Environments
Organizations must be able to take multiple levels of risk mitigation to protect the code, as well as the applications. In this section of this tutorial, we’ll take a look at security controls in development to help you understand the different aspects of security controls in development.
Development environments are the collection of systems and tools used to develop and test software and systems prior to their release to production.
Particular care is required in securing development environments, to ensure that security vulnerabilities and back doors are not introduced into the software that is created there. These safeguards also protect source code from being stolen by adversaries.
Security of the Software Environments
To ensure the security of the software programs produced by developers and development teams, the software development environment itself must be protected.
Controls to be considered include
- Separate systems for development, testing, quality assurance, and user acceptance testing: These activities should take place in separate environments, so that various activities will not interfere with each other. Sometimes it is necessary to impose restrictions on developers, experimenters and users to access these environments.
- Don’t use live production data in development, test, or quality assurance environments: In many applications, production instances contain sensitive data such as sensitive or personal information. It is better to use unrealistic data to eliminate the risk of disclosure of personal information as well as sensitive information.
- Isolate from the Internet: Development systems aren’t used for web access or e-mail.
- Event logging: Logging of events at both the OS level and development level, is used to troubleshoot problems. They also give auditors a running history of developer actions.
- Source code version control: All changes to source code need to be managed through a modern source code management system that has check-out, check-in, rollback, locking, access control, and logging functions. These systems are also used to restrict access to highly sensitive code, so that it is accessible by as few developers as feasible.
- Remove administrative privileges: The user account used for coding and testing should not be a local or domain administrator.
- Use standard development tools: All developers on the same team or project should be using the same IDE or whatever coding, testing, and compiling tools they use.
- Use only company-owned systems: Developers should not be developing on personal devices. They should be using only company-acquired and -supported systems, to ensure that these systems are fully protected from malware and tampering.
Configuration Management
Configuration management is usually confused with change management, while they are different. Configuration management captures actual changes to software code, end-user documentation, operations documentation, developer tools and settings, program build tools and settings, disaster recovery planning documentation, and other details of the change.
A centralized code repository helps in managing changes and tracking when and where revisions to the code have been done. This repository can also track versions of an application so that application can easily roll back to a previous version if a new version is not compatible.
Security of Code Repositories
Code repositories primarily act as a central storage point for developers to place their source code.
During and after development, program source code resides in a central source code repository. Source code must be protected from both unauthorized access and unauthorized changes. Controls to enforce this protection include
- System isolation: The system should be reachable by only authorized personnel, and no other persons. It also should not be reachable from the Internet, nor should it be able to access the Internet.
- No bulk access: Developers should not, under any circumstances, be able to check out all modules.
- No direct source code access: No one should be able to access source code directly.
- System hardening: Intruders must be kept out of the OS itself. We have discussed about details how this protection, in security architecture and engineering domain.
- Check-in approval: All check-ins should require approval of another person.
- Restricted administrator access: Only authorized personnel should have administrative access to the source code repository software, as well as the underlying operating system, and other components.
- Activity reviews: The activity logs for a source code repository should be periodically reviewed to make sure that there are no unauthorized check-outs or check-ins.
- Restricted access to critical code: Few developers should have access to the most critical code, including code used for security functions.
- Retention of all versions: The source code repository should maintain copies of all previous versions of source code.
- Restricted developer access: Only authorized developers and any other personnel should have access to source code.
- Limited, controlled checkout: Developers should only be able to check out modules when specifically authorized.