Making Security Requirements a Reality


We’ve released a whitepaper: Automated Scaling of Security Requirements. It describes the motivation and methodology behind SD Elements. Here’s a brief summary of points we cover:

  • Most companies rely primarily on testing today for security today, but this approach is risky, expensive, and inefficient
  • Security, business, and development teams often have differing opinions of the risk of security exposures found during testing. This can often lead to security issues not being addressed due to time-to-market pressures
  • Training alone is not sufficient to prevent security defects
  • Creating security requirements is cost-efficient and complementary to security testing
  • Organizations often struggle to make security and other Non-Functional Requirement (NFR) domains explicit
  • A subset of NFR domains, including security and privacy, can be automated by distilling a large body of content based on an application’s properties. For example, providing users an ability to explicitly opt-out of tracking cookies is mandatory for any web-site that is subject to the laws of the European Union as per the European Data Privacy Directive
  • Secure programming guides are ineffective substitutes for tailored security requirements
  • Relying exclusively on a single automated tool without customization for security testing means at least 56% of security requirements aren’t being detected
  • Common types of security requirements not caught by security tools include:
  • Authorization
  • Certain session management issues
  • Compliance issues such as treatment of confidential data for the Payment Card Data Security Standard (PCI DSS) and the Health Information Privacy and Accountability Act (HIPAA) ;
  • Storing and caching other kinds of confidential data
  • Privacy issues
  • Security and other NFR tools can be automated by using the following process:
  • Define basic properties of the software you are building through a survey
  • Review all the requirements in a centralized database against the properties selected in the previous step using Boolean logic rules
  • Generate a set of relevant security requirements with links to corresponding test cases
  • Optionally, import requirements into an Application Lifecycle Management (ALM) tool
  • Validate the requirements using a combination of automated and manual tools, commensurate with your appetite for risk



Previous Article
Why you shouldn’t use the OWASP Top 10 as a list of software security requirements
Why you shouldn’t use the OWASP Top 10 as a list of software security requirements

On February 15, the Open Web Application Security Project (OWASP) came out with its 2013 list of candidates...

Next Article
Imperfect Citizens: The Cost of Ignoring Software Security Requirements
Imperfect Citizens: The Cost of Ignoring Software Security Requirements

Recently there has been a lot of buzz about Perfect Citizen, an NSA program designed to discover security v...