SECURE SOFTWARE DEVELOPMENT LIFE CYCLE
THE REQUIREMENTS PHASE WITHIN A SECURE SDLC EXPANDS ON TRADITIONAL REQUIREMENTS PHASES
WITHIN THE TRADITIONAL SDLC REQUIREMENTS PHASE
THE FOCUS IS ON THE CUSTOMER AND THE USER
THE GOAL OF THIS PHASE IS TO ENSURE THE SOFTWARE CREATED MEETS THE NEEDS OF YOUR CUSTOMER AND THEIR USERS
• The critical security impact of running the software under different conditions, which may present vulnerabilities that can be exploited by cyber-criminals. • 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.
PRE-EMPTING ATTACK VECTORS
WITHIN THE SECURE SDLC THE REQUIREMENTS PHASE MUST ALSO CONSIDER THE DEVELOPERS AND POTENTIAL ATTACKERS
Additionally these engineers establish the security blueprints of the application, which helps to determine how to code the software to withstand attacks, how to engineer the software without bugs that can give cyber-criminals an advantage, and how to design the software to be recoverable after an attack. One of the most critical aspects of assigning security engineers to assist with the requirements phase of the SSDLC is the establishment of mechanisms that track, assign, and analyze security threats and risks in order to aid software engineers in their task of developing secure applications devoid of security holes.
TIME SPENT PRE-EMPTING ATTACK VECTORS AND WEAKNESSES IS MORE COST EFFECTIVE THAN CIRCLING BACK LATER ONCE DEVELOPMENT HAS BEEN COMPLETED
Based on these figures, conducting security tests - and planning ahead to establish security in your software during the requirements phase - can help your business save both time and money.
YOU MUST UNDERSTAND AND PERCEIVE POTENTIAL EVIL USER STORIES, SECURITY STORIES AND ABUSE STORIES
• A cyber-attacker modifies the URL to gain unauthorized access to critical, protected documents in the system. During the requirements phase of the SSDLC, teams can add security stories to traditional user stories that include security requirements that would mitigate the aforementioned, potential threat. • 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
MUST ALSO COVER RISK ANALYSIS
THE PUBLIC RELATIONS AND LEGAL NIGHTMARE OF A DATA LEAK IS PREVENTABLE
• Use security tokens for critical user data over storing credit card numbers • Use strong encryption & hashing over presenting important data in plaintext. • Store token data via strong ciphers.