This article is part of a series of publications based on the OWASP SAMM project, if you are interested in understanding better, I recommend reading the article at this link. Within the Operations domain, there is the Environment Management practice, where we have two flows that are directly related, Configuration Hardening and Patching and Updating. According to SAMM, environment management does not end when the application runs . Management must be done continuously, and for this to be possible, attention must be paid to patches, configurations, and new features released regularly.
In the construction of a secure environment that supports an application, there are a large number of resources involved, such as operating systems, services, frameworks, libraries, etc., not to mention that the environment can be on-premises or cloud. This ends up enabling a variety of technology combinations, which in turn generate rich and distinct environments between different companies. This range of environments, which are the result of different software combinations, currently generates difficulties when security issues come to the fore. There is a need for greater control of updates, more robust configurations that guarantee adequate security, and consequently, the adoption of good practices.
When thinking about environment management, one thing that cannot be forgotten is that applications usually work with a certain stack, that is, a set of software/components used by the application, an example of a very common stack is LAMP (Linux, Apache, MySQL, and PHP). It is worth remembering that although I am talking about an application, the infrastructure where the application is hosted also deserves attention in terms of security. For this, OWASP SAMM brings us two streams (Streams A and B) in environment management, which speak respectively of Configuration Hardening and Patching and Updating. The following section mentions each of the flows and what is expected about their maturity, divided into three levels, gradually. Based on the maturity levels, it is possible to assess whether the team’s behavior expresses maturity in performing activities in the sector.
Configuration Hardening (Stream A)
Hardening is the process of reinforcing the security of the systems, for this purpose, the mapping of possible threats is done so that the protection of the systems can be improved. This practice consists of the following recommendations to reduce or even eliminate vulnerabilities in software, hardware, systems, and infrastructure in general. Basically, through good configuration practices, it is possible to make systems more robust and resistant to attacks, not leaving the entire system installed “by default”. According to SAMM, these are the activities expected by their respective maturity level:
- Maturity level 1: It’s important to secure technology stacks, based on available guidance, whether through vendor documentation or even open-source projects. Another important practice is the sharing of knowledge and experience within teams and, based on that, establishing configuration standards for the stacks used.
- Maturity level 2: Establish baseline protection for all components in each technology stack. It is important to develop configuration guides for the components. And require product teams to apply baseline configurations to all new systems and existing systems. It is important to have someone responsible for the configuration guides, keeping them updated according to the evolution of best practices or component changes.
- Maturity level 3: It is recommended to actively monitor the security settings of deployed technology stacks, performing regular checks against established baseline settings. Ensure that the results of configuration checks are available through reports. When detecting non-compliant configurations, treat each occurrence as a security discovery and manage corrective actions. It is important to review the processes periodically, in addition to reviewing the base configurations and their corresponding guides. Through automated measures such as “self-healing” settings and security information and event management (SIEM) alerts, additional gains can be made.
Patching and Updating (Stream B)
Patching is an implementation of a computer program created to correct failures, it is also possible to update and solve security-related problems. Although Updating is related to Patching, updates are not necessarily failures linked to the software, but everything it may depend on, in addition to being related to updates of services used in the application environment. According to SAMM, these are the activities expected by their respective maturity level:
- Maturity level 1: Identify third-party applications and components that need to be updated or patched, including underlying operating systems, application servers, and third-party code libraries. Teams need to share their knowledge of available updates and their experiences with patches. Teams should also be aware of the versions of all components in use to assess if their products are affected by security vulnerabilities.
- Maturity level 2: Develop and follow a well-defined process for managing patches for components in application stacks and other technology services. Make sure processes include regular schedules for applying vendor updates. Create guidelines for prioritizing component remediation, reflecting your risk tolerance and management objectives. Consider operational factors when determining priorities for testing and applying patches. If you receive an alert of a critical vulnerability in a component while no patch is yet available, triage and treat the situation as a risk management issue.
- Maturity level 3: Develop and use management dashboards or reports to track compliance with patching processes and SLAs. Make sure your dependency management and application packaging processes can support patching at the component level at any time while meeting the required SLAs. Leverage vendor alerts and notifications to learn about vulnerabilities and associated patches, leverage and monitor a variety of external threat intelligence sources to learn about zero-day vulnerabilities.
Conclusion
Security is not just done with implementations within the application itself, the environment can be a significant vulnerable point for attackers, even more so if it is not well managed. It is worth remembering that most of the technologies that are used in the application stack sometimes do not follow good security practices by default. So it’s always worth looking for good configuration practice guides, or even validating with suppliers if they have such material. There are also cases where some components have a dependency on backward compatibility, which can consequently prevent updating certain software or even dependencies within the application.
It can be concluded that to guarantee the operation, it is necessary to have greater control of updates and perform more robust configurations that guarantee security, in addition to using the experiences of the teams to be able to adopt good practices within the environment. It’s also important to remember that vulnerabilities are discovered throughout the life cycles of the technologies your organization depends on, so it’s critical to monitor vulnerability reports and execute patches in an orderly and timely manner across the entire system. We shouldn’t limit ourselves to that, as seen according to the maturity level of each of the flows, many other processes that need to be done, and that collaborate with the evolution of the environment’s security.
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
