| Javascript Feeds RSS Feed Security Dashboard | SearchSecurity.com |
Frameworks on Information security management system, lays down a lot of emphasis on organizational security measures in the form of risk analysis, physical and environmental security, access control, business continuity, etc.. The prominence on implementing security in products developed by the organization however is quite confined.
For instance, if an organization is involved in developing software applications for different business domains, then calls for a more focused approach in implementing the security requirements in software development is needed.
Imagine a typical scenario in an organization having sophisticated Intrusion Detection Systems, CCTV controls, an effective Business continuity plan, and a ready to go cold site. However the organization has software solutions that are vulnerable to attack or applications that are susceptible for manipulation. The loss in this latter scenario would mean a colossal damage to organization’s reputation.
In the present business environment where cut throat competition, unrealistic schedules and bargaining power of customers holds an upper hand, the impetus to address security features in software applications may take a back seat.
The BS 7799-2:2002 addresses the subject in a separate domain, 'Security in System Development and maintenance'.
The aim of this paper is to give an overview on how to integrate security features as part of software application development within the boundary of a generic process model.
A survey report by Gartner states the opposite, "75% of security incidents are at the application level."
Generally, the functional level requirements incorporating the security features like user level authentication and access privileges are explicitly documented as part of requirement specifications. However certain security features like the security of the application in totality from penetration attacks are not explicitly identified in requirements specifications.
From a customer’s perspective such security features though not addressed explicitly might be assumed to be implicit, more obvious in cases when organizations claim to have implemented security systems and hold international certifications.
An approach to inbuild the security features as part of regular SDLC cycle could be adopted by organizations in a simple and cost effective manner.
The scope of system study or requirements study should be widened to address the security aspects of the application from a business point of view. It needs to be mandated to address these issues as part of any requirements specification .
Typical inputs that could be captured are: magnitude and scale of application usage, target audience, potential vulnerabilities for misuse, criticality of information handled by the application, sources of basic attacks / penetration.
When the specification highlights theses issues it triggers the project team to spruce up their risk management strategy at application level. This in turns calls for a move to address proficiently application level risks (functional and technical) and not just restricting the risk management to logistical risks.
Having identified the application risks more elaborately, the most frequent risks need to redirected to test plans and test cases.
The gamut of testing now stretches to test, cases of simple penetration attacks eg: SQL Injection, maintaining separate session ids, log in id, sensitive information retrieval form cache, and attack free error messages.
Such a well pronged testing strategy elicits a more conscious approach to address security related features in Design stage and more prominently in the coding phase . This necessitates to constantly update the coding standards to improvise secure coding .
With such an approach a complete traceability of security requirements in the application is established comprehensively within a typical SDLC model.
The responsibility of a software supplier doesn't end with delivering a defect free product but extends far beyond to ensure delivery of a secure quality product .
Consider an example in which the customer calls a few months after a project sign off to say the product delivered has been hacked into. This hack lead to the loss of critical business information and the cause has been attributed to weak development architecture. This does not do a word of good to the brand image of the organization.
It is imperative for all organizations to inject a security oriented approach into their process model not just for sustenance and growth but to fulfill the confidence placed by the customer on the supplier organization.
In an arena where customer relationship management holds the key, a secured high quality product shall not only ensure total customer satisfaction but it will also energize the supplier organization’s business growth .
