Making Security Requirements a Reality

January 14, 2013


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
4 Reasons Why Developers Don’t Read Secure Programming Guides
4 Reasons Why Developers Don’t Read Secure Programming Guides

At Security Compass, we had the experience of building secure programming guideline documents for a number ...

Next Article
Practical Tips for Wireless Security Assessments in Corporate Environments
Practical Tips for Wireless Security Assessments in Corporate Environments

When a wireless security assessment is performed, its goals typically include 1) identifying anomalies in t...

Learn how you can use SD Elements to integrate security into software development.

Watch Video