The focus of a traditional Software Development Life Cycle (SDLC) is on quickly developing feature-rich, efficient, and productive applications. Where does security fit into this picture?
We understand that projects and applications have complex backgrounds and reasonings behind certain builds. The pressure to quickly produce quality products often-times overshadows implementing detailed security practices into the lifecycles.
We help teams identify where and how vulnerabilities have the potential of impacting your applications and software. In addition, we assist teams in adding the ``secure`` portion to the SDLC for future projects and applications. Contact us in order to learn more or to schedule a meeting.
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.
A comprehensive Secure SDLC includes mandatory risk assessments and threat modeling. This identifies sensitive attack surfaces of software that must be hardened in order to protect critical assets. This important step helps build a threat model for future development projects. This creates a firm development foundation for future projects. Assess any risk directly related to a requirement. Several security risks are innately related to legislation. Legal requirements such as HIPAA, SOX, PCI, etc. will help your business identify additional security-specific requirements.
Legislation could affect the way your company:
• 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.
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.