Application Security

Operations according to SAMM: Operational Management in Application Security

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.

Nova call to action
Related posts
Application Security

Why is software documentation important for developers?

If you are a developer or work with software development, you may have wondered about the importance…
Read more
Application Security

Code Review versus Secure Code Review

In the software construction process, several steps are essential for the development to be carried…
Read more
Application SecurityProduct

The best way to set up an Application Security Testing tool in your CI/CD

In this article, we will approach different ways (and their pros and cons) to set up an Application…
Read more

Deixe um comentário