Security at Software Requirements Specification

Paladion
By Paladion

August 15, 2004

Applications designed with security in mind are safer than those here security is an afterthought. Traditionally security issues are first considered during the Design phase of the Software Development Life Cycle (SDLC) once the Software Requirements Specification (SRS) has been frozen. That's one stage too late.

Security RequirementsApplications designed with security in mind are safer than those where security is an afterthought. Traditionally security issues are first considered during the Design phase of the Software Development
Life Cycle (SDLC) once the Software Requirements Specification (SRS) has been frozen. That's one stage too late.

Business owners who specify the requirements of the application should be aware of relevant security issues. The software specifications they develop should include the security requirements of the application. Why do we say that?

Firstly, the business owners are best positioned to decide on
tradeoffs between convenience to the user and security risks. These decisions (for instance, how to handle multiple failed login attempts) affect usability and require the buy-in of the owner.

Next, if security requirements are not defined during SRS, they tend to get overlooked during design too. A feature that has not been explicitly demanded has a high likelihood of not being considered. For instance, if the intrusion detection capabilities of the application are not explicitly stated, it is unfair to expect the
application to have it finally.

Thirdly, specifying security features at the SRS ensures that Acceptance Tests include testing for those security features, a measure which significantly improves the security assurance of the software being acquired.

Contents of Security Specifications

What are the types of security requirements that SRS should contain?

The SRS should define the authentication requirements in detail. These include the preferred strategy for resolving forgotten passwords, addressing account lockouts, expiring inactive sessions, etc. If certain critical transactions should require re-authentication, this is the right time to specify that.

Auditing and logging requirements of the software are another aspect of the software the SRS should identify. The business owner should specify what activity should be logged, the level of detail required and who should have access to these logs. This assists
designers chose an appropriate logging strategy and capture the details most relevant to the business owner.

Intrusion monitoring requirements are another class of requirements that the owner is best positioned to specify. Increasingly, intrusion detection capability is moving from the network layer to the application layer, as generic network layer intrusion detection systems cannot understand threats specific to a business context. The SRS should specify what activity are considered suspicious, what constitutes potentially fraudulent transactions and what the response should be.

Ensuring the SRS contains these security specifications
can help improve the security of the application
and reduce the cost of re-work later.


Tags: Best Practices

About

Paladion