Secure Software Development Life Cycle Requirements Phase

THE REQUIREMENTS PHASE WITHIN A SECURE SDLC EXPANDS ON TRADITIONAL REQUIREMENTS PHASES

Traditional SDLC models - whether it be Agile, Waterfall, etc. - include several phases through which development teams operate in order to deliver a finished software product.

The Requirements phase is where teams conduct extensive planning in order to set the blueprints and foundation of 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 - and the CTO - to determine what features need to be implemented in the application.

The opinions of stakeholders are also considered in this phase, yet in the traditional SDLC security is generally not contemplated or discussed. The specific goals, needs, features, demographics of the end-users, 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 GOAL OF THIS PHASE IS TO ENSURE THE SOFTWARE CREATED MEETS THE NEEDS OF YOUR CUSTOMER AND THEIR USERS

WITHIN THE TRADITIONAL SDLC REQUIREMENTS PHASE THE FOCUS IS ON THE CUSTOMER AND THE USER

The requirements phase traditionally focuses on the experience of the end-user, and focuses on demographics, features.

Themes such as problems end-users are facing, solutions that the software will present to deal with those problems, services that the product will provide, the user interface (UI) are common. Additionally, architectural decisions such as what the application will look like, what data will be stored, what data will be transmitted, what interactions exist within the system between the user and the application are discussed.  

Finally, what features exist that will be most lucrative and the innovations that will make the software easier to market, the usability of the application that will make the software most presentable to different groups, and the specific groups that are mainly targeted make their way into the conversation.

The aforementioned analysis indicates several things about the requirements phase of traditional SDLCs, namely that this phase focuses specifically on meeting customer needs. The requirements phase includes utilizing complex analyses of what the customer's needs will be 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. Along the development route within traditional SDLC's, producing a minimum viable product (MVP) and obtaining customer feedback is also valued as a top priority.

This again highlights the focus on providing a good user experience while putting security in the periphery. In doing so, traditional models do not consider several key factors, such as:

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

WITHIN THE SECURE SDLC THE REQUIREMENTS PHASE MUST ALSO CONSIDER THE DEVELOPERS AND POTENTIAL ATTACKERS

The Secure Software Development Life Cycle (SSDLC) differs from traditional non-secure SDLC's in several ways across all development phases.

Throughout the different 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.

Security specialists also assist with the actual planning of the software in relation to determining what security features the application should contain, i.e. the security requirements that are established during the requirements phase.

During this phase of the SSDLC, security personnel assist with determining the scope of the software that needs to be hardened, along with determining the probable attack surfaces of the application and what critical sections, at a minimum, will require threat modeling.

In establishing the sections of the application that are most likely to be targeted by attackers, security experts can ascertain likely attack vectors and potential exploits that may be used, and determine how to code the software in a way that does not present critical vulnerabilities.

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

"Prevention is better than a cure." This old adage holds very true in the IT industry, where pre-empting cyber-attacks and exploits can reduce overhead, save millions of dollars, and help to establish credibility amongst your user-base. When developing secure software, it is imperative to identify plausible application weaknesses - and attempt to mitigate them - during development (via SSDLC methodologies) as opposed to developing an insecure application and attempting to remediate the flaws after deployment.

Security experts can identify security weaknesses by carrying out security assessments & tests during the development phases, as determined during the requirements phase of the SSDLC. According to the National Institute of Standards and Technology (NIST), security flaws that are found after production can be 30 times more expensive to fix compared to those found during development, and other estimates actually put the figure at being 100 times more expensive if flaws are discovered post-production.


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

The agile SDLC model uses user stories during the requirements phase to describe software features. 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, 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

An efficient Secure SDLC must also include mandatory risk assessments and threat modeling, which includes identifying sensitive attack surfaces of software that must be hardened in order to protect critical software assets. This significant step helps to build a threat model for future development projects and aids in the establishment of a firm developmental foundation that can be used for future development and updates.

ASSESS ANY RISKS DIRECTLY RELATED TO A REQUIREMENT

Several security risks are innately related to legislation that must be understood and assessed fully in order to avoid costly penalties. Legal requirements such as HIPAA, SOX, PCI, etc. will help your business to identify additional security-specific requirements that your company must adhere to. For example, legislation could affect whether your company must:

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



MAINTAIN A RISK PROFILE FOR THE APPLICATION

Security engineers can also 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 attack vectors. Such profiles also include high-risk areas of code that may be vulnerable to different threats, and includes security methodologies that can be implemented to mitigate such threats.

A comprehensive risk profile can aid development teams in several ways, including operating as a security blueprint or playbook that software engineers can utilize as a guide going forward in the development process.

During the requirements phase, the critical step of documenting and establishing a risk profile helps to make security protocols, features, and methodologies transparent, clear and concise to software engineers, while both answering common security questions and removing assumptions about security related features.

Risk profiles also help with the on-boarding process for new team members.

OUTLINE THE VARIOUS RISK CATEGORIES, SUCH AS LEGAL, REGULATORY OR COMPLIANCE

In addition to conducting a 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 in order to give a better overview of potential risks that must be understood by software engineers and consequentially mitigated.

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.