SECURE SOFTWARE DEVELOPMENT LIFE CYCLE
TRADITIONAL REQUIREMENTS PHASE
We offer guidance to help you insert security through positive AND negative testing, assistance in writing evil use cases, and a background of security stories during requirements and threat modeling.
Contact us in order to learn more or to schedule a meeting.
THE REQUIREMENTS PHASE WITHIN A SECURE SDLC EXPANDS ON TRADITIONAL REQUIREMENTS PHASES
TRADITIONAL SDLC REQUIREMENTS PHASE FOCUSES
ON THE CUSTOMER, NOT ALWAYS SECURITY
THE REQUIREMENTS PHASE ENSURES THE SOFTWARE MEETS CUSTOMER NEEDS
• The regulatory legislations in place that require businesses to prove due diligence in protecting user data & ensuring complete data security.
• Finding security holes in software at the end of the SDLC - or after production - usually results in technical debt and costly remediation steps after the product has been fully developed or deployed.
INSERTING SECURITY INTO THE REQUIREMENTS PHASE
WITHIN THE SSDLC, THE REQUIREMENTS PHASE MUST ALSO CONSIDER THE DEVELOPERS AND POTENTIAL ATTACKERS
THINKING OF SECURITY IN THE REQUIREMENTS PHASE IS COST EFFECTIVE
BY UNDERSTANDING RISKS, YOU CAN BETTER PREPARE FOR THEM
• User passwords must be hashed and ``salted`` with bcrypt to thwart password cracking attacks (e.g. rainbow table attacks). Teams can add an abuse story to anticipate and pre-empt security issues, and to identify attacks in real-time (i.e. attack-driven defense).
• Unauthorized attempts to access portions of a site that are for administration should be logged and support personnel should be notified.
THE SECURE SDLC REQUIREMENTS PHASE
SHOULD COVER RISK ANALYSIS
BREACHES ARE PREVENTABLE
• Use strong encryption & hashing over presenting important data in plaintext
• Store token data via strong ciphers.