Is it possible to Shift Left Security Requirements?

#SoftwareSecurityMyth –Security requirements are Non-Functional requirements and are the responsibility of Architects; Business cannot be bothered with these requirements.

The Problem

I often hear that "Software Security is an exclusive domain of Security Specialists or Architects. We cannot bother our business stakeholders with security related technical questions. These are the questions that our Architect must answer and take ownership of realization."

Rightly so, if you go and ask questions like “Give me requirements related to Repudiation threat?” or “Which encryption algorithm to use?” or “Do I need to use One way SSL or Two way SSL?” – I am sure business won’t be able to answer them.

This means security concerns are pushed down to the "Design and Implementation" phase and that is already too late. Moreover, business has no stake in Security requirements - they are not as involved in this phase compared to Requirements phase - this is a bigger concern, as it leads to Security requirements are seen as "speed bumpers" and not as "business enablers".

But does this mean that we cannot “Shift Left” capturing of Security requirements?

How to Address this Situation

If you go through OWASP Top 10 Security Risks, which is published here and here, you will realize that many of these risks can be addressed if we write our User Stories in a more comprehensive way.

Here are few examples:

If you consider most of the #InjectionAttacks, they occur because of inadequate input validation, if we clearly define what is allowed values at the each User Story level, it can help us better contain such issues leaking to the production.

Similarly, #MassAssignment is an issue when requirements are vaguely defined in terms of which attributes are allowed to be updated by the clients (API requests) and developers take the (un)educated guess to update everything coming in the request.

Another, security risk #BrokenAuthentication which is linked to successful brute force attacks can be avoided by adding requirements of locking account after reasonably finite failed attempts (a case of missed requirements for Exception scenarios).

These are just few examples. If you look at these scenarios/requirements, they may not even appear as security requirements and still, having these scenarios taken care of means building effective defense against top security risks by embedding security at the User Stories level.

To Summarize - following detailing can help embed security requirements at the User Story Level:

• Define set of User Roles and corresponding Access Control matrix (what actions are allowed and what are not)
• The above can also include the fact that User Story operates under Authenticated Context (Admin/Manager/User etc) or Unauthenticated Context (Guest/Visitor etc); Internal User (Agent/Employee etc) or External User (Customer/Dealer etc)
• Clearly articulate which Input fields are expected from User (UI)/Client (API) & their permissible (whitelisted) values (validation rules) – Includes Creation, Updations and Deletion scenarios
• Clearly define (& limit) information that must be returned back to the User (UI)/Client (API) – this means don’t send information that is not required by clients
• Identify business exception scenarios and their corresponding actions
• Define which locations are allowed locations for the User (UI)/Client (API) to access the functionality – #geofensing.
• Identify Business Events or Status changes that must be logged as Audit logs (e.g. Password Reset request) and describe the acceptable User behavior (deviation from which must be described in Business Exception Scenario to take appropriate action)

While above list is mostly about embedding security concerns in the User stories (without explicitly calling them security requirements), there are cross cutting concerns that you don’t want to repeat in each User story (e.g. Supported Browser Versions) - those still needs to be added (along with treatment of what to do if unsupported browser is being used to access the system) as separate User Stories.

To Conclude

It is a myth that Software Security is responsibility of a select few, but Security is everyone’s responsibility and security risk can be considerably mitigated by strengthening upstream processes in SDLC without making it sound very technical.

#SecureSDLC #SecurityInAgileProjects #NFRStories #SecurityByDesign