In the same vein, the absence of prior failure does not provide an indicator of future success. It was precisely this belief that helped doom the Challenger STS-51-L mission:
We have also found that certification criteria used in Flight Readiness Reviews often develop a gradually decreasing strictness. The argument that the same risk was flown before without failure is often accepted as an argument for the safety of accepting it again. Because of this, obvious weaknesses are accepted again and again, sometimes without a sufficiently serious attempt to remedy them, or to delay a flight because of their continued presence.(Rogers Commission, STS-51-L)This is not to say we do not implement controls in the environment the system is deployed to provide safety and security. Instead, those controls cannot account for or reverse bad planning, design, or implementation.
It is the responsibility of those performing the implementation - of any system - to ensure that the system under design is developed using a Secure Development Lifecycle.
For Software Development, there are six touch-points, each with associated activities, that must be performed to address security requirements:
- Requirements and Use Cases
- Abuse Cases / Attacker Stories
- Security Requirements
- Architecture and Design
- Risk Analysis
- Test Plans
- Risk Analysis
- Risk-Based Security Tests
- Code
- Code Reviews
- Tests and Results
- Risk Analysis
- Penetration Testing
- Feedback from Consumers (the field, customers)
- Penetration Testing
- Security Operations