Traditional SDLC models such as, Agile, Waterfall, etc. include several phases for development teams to operate in order to deliver a finished software product.

The Requirements Phase - where teams conduct extensive planning in order to set the blueprints and foundation for the software that will be implemented by software engineers. Traditionally this step would involve a meeting amongst every key member of a development team, along with certain executives such as the CFO to determine the financial budget for the software. The CTO would determine what features need to be implemented in the application. Stakeholders can also voice opinions during this phase.

In the past traditional SDLC, security is generally not contemplated or discussed. The specific goals, needs, features, end-user experience, timeframe, and finances associated with the project usually take precedence. It is also important to note that this phase - called iteration 0 in Agile - differs depending on the SDLC model that is utilized. While this phase may be more comprehensive in the Waterfall model due it's nature of presenting unchanging goals, Agile development, which focuses more on modular, flexible steps and goals that are known to potentially change, has a much shorter requirements phase.

The requirements phase traditionally focuses on the end-user experience. Common discussions during this phase include, architectural decisions, application appearance options, what data will be stored and transmitted, and interactions that may exist within the system between the user and the application. Lastly, the features that make the application or software marketable are discussed.

The requirements phase includes utilizing complex analysis of what the customer needs and how the software will meet those needs. In addition to this, the requirements phase - like most phases of SDLC models - focuses on releasing products that are feature-rich and perform well, as quickly as possible. Getting the product to market quickly, return on investment (ROI), innovative features, and increasing revenue become a primary impetus for software development.

• 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.

During this phase of the SSDLC, security engineers assist in determining the scope of the software that needs to be hardened. They determine the probability of attack surfaces in the application and what critical sections, at a minimum, will require threat modeling. In establishing the areas of the application that are most likely to be targeted by attackers, security experts can project and prevent likely attack vectors and potential exploits.

The Secure Software Development Life Cycle (SSDLC) differs from traditional non-secure SDLC's in several ways across all development phases. Secure SDLC's include the assignment of security engineers to development teams in order to oversee the development process, conduct code reviews and security testing, and to guide the use of secure coding in software projects. Even more effective? Teams often train their developers to become security focused. These engineers establish the security blueprints of the application. This helps determine how to code the software to withstand attacks and how to develop software without bugs that can give cyber-criminals an advantage. They design the software to be recoverable after an attack. Security Engineers are critical in the creation of the requirements phase of the SSDLC. They establish mechanisms that track, assign, and analyze security threats and risks in order to develop secure applications, devoid of security holes.

Development teams can write evil use cases and security stories during requirements and threat modeling.

In a SSDLC, evil user stories can help developers take on the persona of attackers, which - combined with the white-hat persona (defensive cyber-specialist) - can assist with developing a secure application by shifting to an attacker's mindset.

Some examples include:

• A cyber-attacker modifies the URL to gain unauthorized access to critical and protected documents in the system.

• 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.

Security engineers aid the development team during the requirements phase by creating and presenting a risk profile for the application. The application's risk profile includes sensitive areas of the software, along with areas of the software that present attack surfaces that may be susceptible to certain attacks. Such profiles also include high-risk areas of code that may be vulnerable to different threats. During the requirements phase, the critical step of documenting and establishing a risk profile helps to make security protocols, features, and methodologies transparent to software engineers. Risk profiles also help with the on-boarding process for new team members.

While creating and conducting comprehensive risk assessment, security engineers - during the requirements phase of the Secure SDLC - conduct the critical step of understanding, analyzing, and categorizing the various risks to the software application. During this process, it is helpful to categorize the various risks using a variety of security frameworks such as the OWASP Top 10, SANS CWE Top 25, or OWASP ASVS.

Once the security requirements of the software are clearly understood by the entire development team, it is time to move into the design phase and begin building a secure architecture for the application.