In modern computer software development, it is very easy to lose focus on security in the face of rapidly shifting functional requirements. However, security requirements gathering can turn out to be the most important development activity.
The extensively networked nature of modern applications has made security a tremendous concern. Security flaws may not become readily apparent until a project has been live for many months. Due to these factors, we are increasingly seeing security becoming a shared responsibility. In fact, the responsibility for defining security requirements often extends beyond a development team and out towards the entire industry in the form of standards and best practices.
When a project carries explicit security concerns, such as in a defense or banking project, there is often a security architect or audit team that mandates security requirements for the project. However, even a casual mobile application should be developed with security requirements in mind.
While functional and non-functional requirements generally come from customer flow-down first and from technical assessment second, security requirements have many dimensions. While they may be customer generated or derived from the technical design phase of a project, there are additional sources of security requirements:
- Industry/government security standards Standards from a governing body may dictate certain diligence in security review, and the product may be beholden to PCI DSS, HIPAA, and other such requirements.
- Industry best practices While no formal security standard may cover the components of a product, some security best practices are part of the due diligence of software development. For instance, if a project transmits login credentials in clear text over its application, it may not be formally ignoring any requirements, but it will be exposing the project to far too much risk. Practices such as this can be looked upon as “de facto” standards.
- Automated Security Assessment Many organizations are turning to automated security assessment tools, such as Coverity, Veracode, and Fortify, all of which enable security scans that identify potential vulnerabilities. A project can mandate these scans as part of its build process, and it also has leeway over how much risk it is willing to accept with the results. However, they become an additional source of security requirements that may have been missed in the phase of assessing the project against formal and informal standards.
The process of security requirements gathering involves a great deal of communication between the customer, project management, and all teams involved in development. We also cannot ignore the best practices and standards for security that come from the wider industry. No amount of communication overhead and preparation is too much if it means ensuring the safety of systems and data. Let us know how we can help you with your security requirements.
