In this article, we will continue the series of publications on the OWASP SAMM (Software Assurance Maturity Model) by addressing the security practice related to Operational Management in Application Security, within the Operation domain.
When we think of application management, usually, the first thing that comes to mind is risk and vulnerability management, but we should not think only about this.
According to the OWASP SAMM, to have a good Operational Management practice, we must focus our activities on ensuring that security is maintained across all operational support functions, creating technical and administrative controls to ensure security in managing your application data, assets, and legacy components.
Operational Management, according to SAMM, is divided into two main streams:
- Data Protection
- System Shutdown / Legacy Management
In this article, we will see what is expected to reach a higher maturity in these two streams.
Operational Management in Data Protection
At a lower level of maturity, the business is expected to have at least an insight into the types of data used by its applications, know how to classify it, and have basic management controls.
Maturity increases as controls become more robust and automated, where at a higher maturity, the organization uses tools to assist in its data management and decreases human effort.
Level 1
At this first level, the business is expected to understand the types and confidentiality of data stored and processed by its applications.
The organization needs to control the destination of the processed data (for example, backups, sharing with third parties/external partners, etc.) and always keep informed and up to date with the control created.
Finally, the business can implement basic controls to better manage its applications and prevent the propagation of unsanitized sensitive data from productionto lower environments.
Level 2
At this maturity level, it is expected that data protection activities will focus on managing the application data.
Technical and administrative controls must be established to protect and maintain the confidentiality of sensitive data and the integrity and availability of all data under the care of the business.
These controls must be in place throughout the entire lifecycle of the data, from the time the company or business area receives the data until it is disposed of.
It is essential to mention that data disposal and retention must be carried out in accordance with the company’s Data Retention Policy.
The business needs to map the data stored, processed, and shared by its applications, so that it can classify by level of sensitivity and type.
The company needs to clearly understand its data records subject to regulations (e.g., LGPD, GDPR, and so on).
When mapping is put in place, in addition to providing management over application data, it also increases the accuracy, timeliness, and efficiency of your responses to audit-related queries, incident response teams, or customers and facilitates threat modeling and compliance-related activities.
Based on your Data Protection Policy, create processes and procedures to protect and preserve data throughout its lifecycle.
Level 3
At this last maturity level, the activities are focused on data protection automation, with the aim of reducing human labor to assess and manage compliance with policies.
It is important to monitor attempted breaches, and to use available tools for data loss prevention, access control, and anomalous behavior tracking or detection.
In addition, automated operations should be periodically audited to assess whether they comply with company policies, including backup and record deletion processes.
System Decommissioning / Legacy Management
In this flow, the maturity level increases as the company improves controls over its legacy assets and component, or those that will become legacy in a specific period.
At a lower level, the business is expected to have a clear view of its legacy assets and manage the migration of users to newer versions.
At a higher level, the organization has controls that evaluate the life cycle of the asset or component, so it can anticipate its customers and users in cases of support termination in older versions of the application.
Level 1
At the first maturity level, the business is expected to map its applications or assets that are no longer used, perform additional operations for these cases, and establish a formal process to decommission them.
There is a need to manage the migration of clients/users of older versions of your applications, and when there are no users in any version, discontinue support for that version.
Level 2
To achieve this level, the business must follow an established process as part of their application decommissioning, removing all irrelevant accounts, firewall rules, data, and so on from the operating environment.
There should also be a process for validating updates to third-party applications or dependencies and replacing those that have reached the end of their useful life.
Support documentation for all released versions of your products must always be available in an accessible location.
Level 3
At the last maturity level, the business is expected to regularly assess the life cycle state, the support status of each asset and the components of its applications, with the aim of estimating their end-of-life.
With the estimated lifespan of your components and assets in hand, define a product support plan, providing clear timelines for ending support on older versions of the application.
In possession of this planning, inform your customers and users when you discontinue support in previous versions.
Actively track the security risks that arise in your assets and components as they approach the end of their useful life, and draw up plans to mitigate them.
Finally, review and update the entire process at least once a year.
What can we conclude about Operational Management in application security?
We must look at the data that our applications will use and create technical and administrative controls for the protection and proper disposal of that data. We must not fail to comply with the regulations that the organization is subject to.
Another critical point is to always look at our assets and components and have a concrete plan about what is, and what can be, legacy.
Remembering that if we act proactively by mapping the life cycle of our assets/components, we can anticipate and adequately plan the decommissioning of a system, and thus devote time and effort to other activities.
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