Once software is designed, built and tested, it needs to be deployed to a live environment to bring value to the customers who use the software. How software is deployed and what activities occur during its operation on a live system will play a significant role in determining the security of the software system. The Operations business function of the OWASP Software Assurance Maturity Model (SAMM) covers the post-deployment activities that are necessary to maintain the security of the deployed software. It breaks down the operations function into three business practices, each of which I will explore in this blog post:

Incident Management

The first stream in the Incident Management practice is incident detection. When software is live on production systems, it needs to be monitored to determine if its functionality, performance and security are maintained within acceptable bounds. To do this effectively, logging is essential. For security, logs must be detailed enough to not only help identify when security incidents occur, but also to provide enough information for users to understand the severity and nature of the incident. Logs by themselves are not helpful without continual analysis. Smaller organizations may manually perform log analysis, but as the organizations scale up, it is necessary to automate this process as much as possible. Automated systems that integrate information from multiple sources are key. Events from these different sources can then be correlated to help detect security incidents. Incident detection should be a well-defined process with a designated owner, so that the process may be reviewed periodically and improved as necessary.

The second stream in the Incident Management practice is incident response. Once an incident has been discovered by the incident detection process described above, action must be taken to properly handle the incident. At a minimum, there should be a single, well-known point of contact in the event of an incident. It is also important to document all activities that occur during the response, as well as protect that documentation from unauthorized access. As an organization matures, the incident response process should become a formally described process with a dedicated incident response team. The team should engage in root cause analysis (RCA) of incidents and perform post-mortem reviews to develop lessons learned. As global threats continually evolve, stakeholders should also continually review and improve the organization’s incident response process.

Environment Management

Software must run somewhere, and it is necessary to secure the location in which it is run. The set of hardware components and software components required for the software to run is referred to as the software’s environment. To help evaluate the security of an environment, one should ask two questions:

The streams of the Environment Management business function address these two questions. They are Configuration Hardening and Patching and Updating. Both practices require the maintenance of an inventory of hardware and software components.

Proper configuration plays a vital role in securing the environment where the software will be running. After developing an exhaustive inventory of components, it is necessary to create configuration standards for every component. One should develop secure baseline configurations for all technology stacks and a repeatable process for applying these configurations. An assigned owner should be responsible for managing changes to the baseline, which are maintained using a change management system. These baselines should be periodically reviewed to ensure compliance with the latest industry best practices.

Outdated components are a significant source of security issues, and the root cause of many high-profile breaches involves the use of vulnerable, outdated components. If the components had been maintained, then many of these breaches could have been prevented. It is best practice to establish a regular cadence of patching for all the components. The patches should be subject to standard change management best practices. To maintain the availability of the system, it is important to properly test patches before deploying them to production. One should track the vulnerabilities for each component using threat intelligence sources and notifications from component vendors. It is also necessary to establish SLAs for patching components, as well as develop a process for the emergency deployment of critical security patches. To continually determine the effectiveness of the overall patching process, periodic reviews are key.

Operational Management

The final security practice for the Operations business function is Operational Management, which consists of the Data Protection and System Decommissioning / Legacy Management practices.

Throughout the course of software operation, there will be times when sensitive data is handled and stored. Protecting this sensitive data is one of the key activities of security operations. Like with environment management, protecting sensitive data starts with an inventory. In this case, it is an inventory of the data that is used within the environment. The data needs to be classified according to sensitivity levels to help determine the controls necessary to protect the data. One should take into account any applicable laws or regulations, such as GDPR, when determining the controls used to protect that data and any processes around data management. These decisions should be codified in a data protection policy, and it is important to continually monitor the system for policy violations. Automated monitoring is helpful here. It is important to handle data when at rest, during transit and during processing. The data inventory should be regularly reviewed to ensure that it is up to date and that new sensitive data is properly accounted for.

When the components of the software system approach the end of their lifecycle, it is necessary to securely dispose of them. One should develop a process to handle the decommissioning and transfer of data from components. All components’ end-of-life notifications should be monitored and used for planning decommissioning activities. Unsupported components should never be present in the production environment. To foster transparency, it is important to publicize the component decommission dates to all relevant stakeholders. For any customer-impacting changes, one should implement a plan to notify the customers of the date and impact of a component’s end of life. Finally, the process itself should be reviewed periodically to find and address any shortcomings that may be present.

Operations is where the rubber meets the road, and where the developed and tested software makes contact with reality. It is where the software system will be the most exposed to external threats, so it is vital to integrate security practices into the day-to-day activities in the operational environment. The OWASP Software Assurance Maturity Model (SAMM) provides guidance on practices to implement for maintaining a secure operational environment, as well as measuring the maturity of those practices. OWASP SAMM should be included in the toolkit of anyone diligently seeking to improve the security of their software development process.