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 You Should Define Software Security Requirements for Mature Applications
4 Reasons Why You Should Define Software Security Requirements for Mature Applications

There’s a common misconception that security requirements are only useful for net new applications. Most pe...

Next Article
It’s Cool to Care about Security Requirements
It’s Cool to Care about Security Requirements

We at Security Compass are thrilled to be named Gartner Cool Vendor 2014 for the Application & Endpoint sec...