Operations according to SAMM: Application Security Incident Management

Leandro Cabral

3 anos atrás

Continuing the series of publications on the OWASP SAMM framework (Software Assurance Maturity Model), in this article we will address the practice of Incident Management in Application Security, within the Operations domain.

Imagine a scenario, where we had a security incident with one of our applications and now we need to understand what we should do. First, let’s understand what a security incident is.

Application security incidents: what is it?

In short, a security incident refers to any unauthorized or suspicious access, disclosure, modification, or destruction of your application’s data.

In fact, when there is a security compromise of your application, then at this moment we have a Security incident.

In this sense, we need to have a path and a set of clearly defined responsibilities for which the team will act or who will be called to deal with the situation. Remembering that as the OWASP SAMM itself mentions:

“Many security incidents have been detected months, or even years, after the initial breach. During the ‘wait time’ before an incident is detected, significant damage can occur, increasing the difficulty of recovery. Our first stream of activity, Incident Detection, focuses on decreasing this dwell time.”

The sooner we know when the incident happened, the quicker we can respond and act on it.

Steps in case of application security incidents

If a security incident occurs with your application, you can follow these steps:

Identify the root cause of the incident, for example by looking at logs, reviewing code, etc.
Determine how long the security issue may have been present;
Determine which users of your application were affected and all information that was or could have been compromised;
Confirm that any end-user data may have been compromised.

Keeping a few questions in mind is also very important:

Could the security incident have had any impact on end-user data? If so, will these end users be notified in accordance with applicable laws or contractual agreements?
Do you have an estimated time frame for waiting for the incident to be resolved?
What is the category of security incident that occurred, vulnerability, intrusion, data leakage?
What corrective actions were taken to remove the root cause of the incident and prevent similar incidents from occurring in the future?
What is your plan for communicating with end users about this incident?

This is something that should already be planned, having an incident response plan and having all the steps to resolve it as quickly as possible is essential!

This can be done by following a few steps:

Identify your application’s weaknesses.
Protect access to sensitive parts of the application.
Strengthen security perimeters against future attacks.
Unsuccessful attempts should be treated as incidents, this can prepare you for future attacks.

Conclusion

The last phase is to learn from incidents that have occurred, lessons to be learned: Review incident logs to check for possible weaknesses in your configuration, adjust WAF rules and verify or introduce new policies, and always test new rules and stay tuned to false positives.

The incident response lifecycle must be worked on constantly, analysis and detection must flow after the incident to have valuable learning and thus continue to improve your application security and be prepared for future incidents.

Application security incidents: what is it?

Steps in case of application security incidents

Conclusion

SAMM article series