Read the whole article at the Security PS Blog: Non-Negotiable Elements of a Secure Software Development Process: Part 3 - Validation Criteria
In September, I gave a presentation focused on helping quality assurance professionals understand how they fit into a secure software development process (SSDP) and how they can take an active role in improving software security. In that presentation, I discussed essential elements that make up a successful SSDP. These elements are: security requirements (expectations); secure architecture, configuration, and coding patterns (how to satisfy an expectation); and validation criteria (verification that expectations have been met). These elements allow an organization to be transparent regarding its security goals and performance. They also facilitate communication with customers, developers, managers, and other project stakeholders.
This article is part 3 in the Non-Negotiable Elements of a Secure Software Development Process series and focuses on defining validation criteria. In part 1 of the series, we discussed how security requirements set clear and reasonable expectations that development teams can plan for and meet to satisfy a specific level of security assurance. Part 2 discussed how to use secure architecture, configuration, and coding patterns to satisfy security requirements and reduce the ongoing cost of developing secure code.
Why Validation Criteria?
Many organizations measure how secure their applications and infrastructure are using assessments. They might use application security assessments, penetration tests, design reviews, threat models, or many other fault finding activities. These can be good risk indicators, and they are often important activities to include within an application security program, but they fall short in actually telling us whether our application is secure. They focus on finding problems, telling us when an asset is insecure, and remain silent about everything else.
With the declaration of security requirements and secure architecture, configuration, and coding patterns (secure patterns), we now have a list of positive characteristics about the application that we would like to affirm. If we can validate these elements, then we can get a more comprehensive understand regarding how our application is secured. We can then focus on using assessments to identify missing security requirements and improve our overall process as a whole instead of a single application.
Read the following additional sections of the article at the Security PS Blog: Non-Negotiable Elements of a Secure Software Development Process: Part 3 - Validation Criteria
- Why Validation Criteria?
- What to Validate?
- Validation Criteria Approaches
- Test Case Techniques
- How to Win at Software Security
Posts
