Continuing the series of publications about the OWASP SAMM (Software Assurance Maturity Model) framework, we will now approach the security practice related to Secure Deployment within the Implementation business function. If you still have no idea about the composition and organization of the framework, I recommend reading our first article which explains it in more detail.
Anyone who has been working in the Information Technology area for many years knows that before the advent of virtualized environments, cloud computing, and DevOps, the deployment of an application involved too many risks. For many companies that still work in the waterfall model, it still does. Entire teams of engineers and software architects, database administrators, and infrastructure analysts would work late at night and even during weekends to provide users with a new software feature.
Times have changed and many of these difficulties were left behind with the use of solutions based on continuous integration/delivery pipelines, cloud computing, and microservices, in which the deployment of an application is usually done after a build that generates the software package along with all necessary libraries, dependencies and environment variables in a container. This avoids compatibility problems and drastically reduces the risks related to service unavailability, and makes the rollback process easier.
But with the changes in application deployment processes, there were also changes in the risks involved.
We will analyze how OWASP SAMM helps us to gain maturity in the deployment of applications, listing the main requirements to move from the current state to the maximum level of maturity (Level 3) in the two chains related to this practice: Deployment Process and Secret Management.
Deployment Process
A Deployment Process, according to SAMM, advances in security maturity levels as controls are implemented to ensure the automation of the pipeline, including documentation, logs, security tests, and observability. At the top, we will have a completely automated process, supervised by a specialized technical team, with all software dependency relationships and package integrity being checked by digital signatures and certificates autonomously.
Level 1 Requirements
- Centralized documentation describing the entire Deployment Process;
- The deployment of applications should not be done by developers;
- Hardening and tuning of automation tools. Principle of Least Privilege;
- Analysts with high technical skills.
Level 2 requirements
- Fully automated deployment;
- Integration of DAST and vulnerability scans;
- Registration of test results and automated notification for the responsible person;
- Automated quality control, blocking or reversing critical errors;
- Registration and auditing of all deploys.
Level 3 Requirements
- Automatic checking of digital signatures and certificates of software packages, dependencies, and artifacts, your own or third parties;
- Deployment blocking when components don’t have signatures and certificates checked;
- Application of the principle of observability whenever possible and necessary.
Secret Management
A Secret is an object that contains a small amount of sensitive information.
Secret Management involves protecting the lifecycle of credentials, tokens, passwords, and other sensitive information through the consistent application of security policies. The correct and secure management of access credentials is one of the main challenges for software factories today. Some of the most serious data leakage events are due to flaws in this process that could be avoided.
OWASP SAMM also deals with this matter to guarantee the necessary directives to guide us on the best practices of credential management. It does it by observing the basic principles as the non-availability of production environment credentials to developers and cautions with access keys hard-coded to implement automated scans on files and code repositories to prevent unauthorized people from accessing them.
At a higher level of maturity, software and security companies have their team working only on managing the lifecycle of these credentials, ensuring that they are renewed from time to time and guaranteeing access only to duly authorized people.
At the top level of security maturity, software companies have a special team working only on managing the lifecycle of these credentials, ensuring that they are renewed from time to time and guaranteeing access only to duly authorized people.
Level 1 Requirements
- Developers without access to production environment secrets and credentials;
- Configuration files of test environment without secrets or credentials;
- Use of production environment credential management tools with access granted only to the responsible person.
Level 2 requirements
- Automated process to add credentials inside configuration files during deploys;
- Automated scans to search for credentials and secrets in files and repositories;
- Use of encryption for credentials and secrets, at rest or in transit;
- Maintenance of the password vault with the principle of Least Privilege.
Level 3 Requirements
- Lifecycle management of production environment secrets and credentials;
- Logging and auditing access logs to credentials and secrets, whether reading or writing.
Clarity brings security
Conviso Platform presents Secure Pipeline, a solution for orchestrating automated analysis of the development trail that integrates with the most various market vendors. In the picture below we have a dashboard view of the risks associated with each deployment:
It is clear that the principles which bring us to advance in the application security maturity levels are automation of package delivery processes, hardening, and tuning of the tools used in the process, the delegation of responsibilities to well-formed people in the organization, and effective management of access credentials. And it accomplishes it all without ever leaving aside the important principle of observability.
It becomes clear how the OWASP SAMM framework can help us to see our current level of maturity in Secure Deployment. With this clarity, it is easier to think about solutions and create implementation projects so we can advance even further on this scale, whether in the Deployment Process or the Secrets Management stream. Both are very important to construct even more secure applications.
SAMM article series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security