With all the interconnected devices in the world, integrated seamless communication is a must. This always-available access is seemingly at odds with the goal of security. Additionally, the way in which applications are built has changed over time with many companies merging agile techniques with development and operation processes. The IoTAC project aims to incorporate security into each step of the software lifecycle, building security into every component and employing new techniques extracted from established industry standards and best practices. Here we will focus on the release and deployment phase, but it should be understood in the larger context of the IoTAC security approach.
Figure 1: Security during Release/Deploy phase – IoTAC Methodology
The release and deploy phase methodology is comprised of:
- Release process automation
- Environment management
- Performance Testing
- Dynamic Application Security Testing
- Secure hardening verification approach
A key element to a secure release is automation. By using a CI/CD tool like GitLab you can remove error-prone manual steps and ensure consistency. Part of this automation includes checking the origin of the artifacts that your automated process creates. This allows you to sign and verify that the build has not been tampered with and you deploy only what you intended. Your application configuration also needs to be intensified. A common mistake is storing secrets in the source code. This is often overlooked in feature branches, but since the branch history is always available it poses a real threat. If you don’t use a dedicated secret management service, be sure to encrypt your secrets, and regardless of your means of storage only allow the application and a well-defined small group of people access to the settings.
An important piece of the automation pie is to include release pipeline integrity and execution. Again, limit pipeline access to a small well-defined group and ensure changes are monitored and logged. One way to accomplish this is by storing the pipeline definition in the source code repository and enforcing code reviews on branches used to deploy to Staging and Production. As for pipeline execution, it is best to have a manual approval step. This ensures nothing goes to Production without the knowledge and acceptance of key stakeholders. Be sure to log each deployment keeping track of a minimum of when it was deployed, what version, and who approved it.
Managing your environments with security in mind is crucial. Usually, this is broken down into Development, Staging, and Production to serve the needs of various stakeholders. For the development environment, no sensitive production data should be used to avoid accidental leaks. The staging environment should be configured as much like production as is possible including the same automated deployment process. Once the development is completed and all automated tests have run successfully, the application is deployed to the staging environment for further automated and manual testing. The production environment is for the end-users, but the Dev team will need secure access to investigate issues without compromising security. This can be done with monitored jump servers and applying data encryption so that crucial application data is not even available to the maintenance team. The environment setup and configuration must be documented and preferably automated. You can automate using Infrastructure as a Code which is an approach available, for Kubernetes or in Cloud environments.
Performance testing is another key element of application reliability, so it is recommended to perform a volume stress test that simulates requests and client actions. This requires test scenarios that generate a detailed report that can be evaluated and compared for negative impact. If changes are required the whole delivery pipeline should start over. The testing should validate the application is protected from Denial of service (DOS) attacks by either software or hardware components.
Dynamic Application Security Testing (DAST) needs to be implemented as well. DAST focuses on clearly defining a security baseline and having the deployed application employ vulnerability and patch-level scanning. The security baseline is defined for the specific component, including application binaries, application configuration, and infrastructure configuration. This will help to recognize any configuration drift between environments.
The secure hardening verification approach executes security validation in Staging to catch issues before being implemented in Production and it is also run periodically in Production to ensure safe operation. This includes vulnerability scanning of the infrastructure and application code, configuration management, penetration testing, Distributed Denial of Service (DDOS) validation, and following the principle of least privilege. Even with comprehensive automation, some things cannot be easily automated. To fill this gap Red teaming is recommended using a team of security professionals not related to the DEV team. They can perform penetration tests, test for SQL injection, and otherwise, try to infiltrate the system.
Secure release and deployment is not a simple endeavour, but following the release and deploy methodology as part of the IoTAC’s security approach is a surefire way to allow seamless communication with the utmost protection.
References
- Application and Release Security in GitLab https://docs.gitlab.com/ee/user/application_security/
- Delivering Quality Services https://docs.microsoft.com/en-us/devops/deliver/delivering-quality-services-with-devops
- Security in DevOps https://docs.microsoft.com/en-us/devops/operate/security-in-devops
