midimage
sideimage

SECURE SOFTWARE DEVELOPMENT LIFE CYCLE

DEVELOPMENT PHASE (SSDLC)

GET MORE INFO

ON THE DEVELOPMENT PHASE

SECURING THE DEVELOPMENT PHASE

OF THE SDLC

THE DEVELOPMENT PHASE

The focus of a traditional Software Development Life Cycles (SDLC) is on quickly developing feature-rich, efficient, and productive applications.

They often put security issues in the background, which results in security vulnerabilities being found far too late in the post-production stages. Security planning needs to begin at the very root of the SDLC, during the requirements phase - which focuses on establishing the blueprint of the application and determining what features are required to be in the app. Security also needs to be a primary focus in the design phase - which determines how to implement the required features - and the development phase - which is the actual coding phase that brings the requirements to actuality according to the blueprint and design specifications.

This means that the planning and preparation are done in the previous SDLC phases; in the development phase of the Secure SDLC all modules, components and architectural structures of the application are developed, and engineers don't have to make arbitrary assumptions about how to correctly implement security into the software. The blueprint, implementation plan, and security strategies - based on risk management strategies, architectural risk analyses & threat modeling, etc. - set forth in the previous SSDLC phases - are a guide for software engineers to follow, such that the design and architecture of the finished product should be indicative of a secure system.

Verification of the application's security - as well as the secure coding of the application - are both necessary during the SSDLC, which not only ensures data security but also ensures that the application is meeting the business requirements and is in compliance with required legislation.

IN THE CODING PHASE OF THE SOFTWARE DEVELOPMENT LIFE CYCLE VULNERABILITIES ARE PREVENTED BEFORE THEY CAN OCCUR

Traditional SDLC's develop the code of the application without secure coding methodologies, often resulting in several high-risk vulnerabilities that need to be fixed later on in the production life cycle, which can increase corporate overhead and remediation costs.

This is a paramount point in software development as the number of vulnerabilities found in applications continues to grow exponentially. SQL Injection (SQLi) and Denial of Service (DoS) attacks were still among the top attack vectors and a large percentage of web applications scanned are still very vulnerable to cyber-attacks and exploits. In contrast to such traditional development models, the fundamental paradigm of SSDLCs is that prevention is better than a cure, meaning that using secure coding methodologies during the development phase is significant in preventing the existence of high-risk vulnerabilities altogether, which can greatly decrease company overhead and save money.

In conjunction with using secure coding methodologies it is important to utilize code reviews and penetration tests during the life cycle of application development to ensure that code is secure before deployment in the production stages. Correcting and securing code before it is committed to code repositories is an important step in producing not only efficient but also secure code, and this method is also the cheapest way to address application security and a potential myriad of vulnerabilities.

Typical methods of securing the development process includes the use of peer code reviews, unit testing, and static code scanning and analysis. They often put security issues in the background, which results in security vulnerabilities being found far too late in the post-production stages. Security planning needs to begin at the very root of the SDLC, during the requirements phase - which focuses on establishing the blueprint of the application and determining what features are required to be in the app. Security also needs to be a primary focus in the design phase - which determines how to implement the required features - and the development phase - which is the actual coding phase that brings the requirements to actuality according to the blueprint and design specifications.

This means that the planning and preparation are done in the previous SDLC phases; in the development phase of the Secure SDLC all modules, components and architectural structures of the application are developed, and engineers don't have to make arbitrary assumptions about how to correctly implement security into the software. The blueprint, implementation plan, and security strategies - based on risk management strategies, architectural risk analyses & threat modeling, etc. - set forth in the previous SSDLC phases - are a guide for software engineers to follow, such that the design and architecture of the finished product should be indicative of a secure system.

Verification of the application's security - as well as the secure coding of the application - are both necessary during the SSDLC, which not only ensures data security but also ensures that the application is meeting the business requirements and is in compliance with required legislation.

WRITING CODE WITH SECURITY IN MIND IS BETTER THAN CHECKING CODE FOR SECURITY ISSUES LATER

WRITING CODE WITH SECURITY IN MIND

Due to the nature of software engineering, writing functions, classes, modules and software components with security in mind is an extremely valuable method to prevent serious vulnerabilities from being present in IT applications.

It is much more feasible than having to re-write entire blocks of code during post-production stages once security reviews later show vulnerabilities to be present in application code. With this in mind, it is pivotal to have continuous application security training for all software engineers on a regular basis, with annual training being the minimum.This ensures that security best practices are kept in the forefront - not in the periphery - as engineers write code and develop applications from the very beginning of the development phase. IDE security plugins that continually scan code to highlight weak code segments and/or secure code fallacies should be implemented to aid software engineers in writing secure code.

These plugins operate like spellcheckers, but instead of highlighting erroneous grammar they point out weak code and possible vulnerabilities in the code that could be exploited. Some examples are Puma Scan, Brakeman, Codiscope, and Find Security Bugs. While utilizing such plugins greatly aids with writing secure code and keeping security in the forefront to eliminate risks and vulnerabilities before the code is checked into code repositories, they do not replace secure coding methodologies and security coding best practices.

DURING THIS STAGE THE FOCUS IS ON SECURITY UNIT TESTING

SSDLC DEVELOPMENT PHASE FOCUS

During the planning and design phase, different modules and components of the software are planned out according to the original blueprint. During this subsequent development phase of the SSDLC, not only is the application coded but unit tests for each module and component are developed to continuously ensure application security.

Generally, traditional unit testing typically tests sections of software applications without security in mind, yet in the SSDLC this approach must evolve to include security unit tests of each module on a continuous basis. Furthermore, security unit testing must include very specific tests carried out on certain, critical units of the application such as authentication, session management, encryption, validation, encoding, and authorization services, all of which represent high-risk application areas. At this stage of the development process the use of automated security unit testing is vital to assist engineers with securely coding the software application. This helps to eliminate common code vulnerabilities before the code is committed to repositories. Additionally, engineers will be aware that writing insecure code will ultimately result in software builds that will fail unit tests, which helps to keep engineers focused on security concerns and on using secure coding best practices. The critical factor with SSDLC's is that security is always kept at the forefront of all software engineering activities.

POSITIVE AND NEGATIVE UNIT TESTS ARE WRITTEN FOR SECURITY FEATURES AND FUNCTIONS

Security unit testing typically comprises both positive & negatives tests, the former of which is known as the happy path. Positive tests are generally associated with successful and non-threatening activities where everything goes as expected with regard to interactions between the system and the end-user, such as when an authorized user successfully signs into the system. Negative tests are critical and are required to fully test the security of a system's features and functionality. These tests can help engineers utilize best practices and secure coding methodologies such as those associated with error & exception handling, viz. passing an invalid login error message to a user when incorrect credentials are used to access the system.

These tests are also critical in regards to input validation, such as testing how a system responds to a SQL Injection (SQLi) exploit to bypass authentication (that is, a vulnerable login screen) that seeks to sign in when not authorized. If a system allows for a successful login during the aforementioned scenario, then a negative unit test should reveal this.

BUILDING A UNIT TESTING CULTURE WITHIN AN ORGANIZATION

There are several ways to establish security unit testing practices as routine in your organization, such as:

• Scheduling routine security unit testing sessions for engineers to discuss and share ideas and valuable data associated with different testing suites. • Presenting new security ideas and recent security statistics at monthly meetings, lunches and discussions. • Establishing internal wikis to share tests with new team members once a solid number of efficient tests are written. This can help to introduce new members to the testing culture. •Rewarding engineers who build or assist with the engineering of good security tests (e.g. time off, gift cards, food vouchers, etc.).

EXAMPLES OF SECURITY UNIT TESTS INCLUDE

There are several types of security unit tests that your company can utilize, such as:

• Logical checks (e.g. cryptography, session management, authentication). • Security Checks (e.g. access control, entitlement checks on unauthorized accounts). • Defensive Code Checks (e.g. validation, encoding, error handling).

UTILIZING MANUAL PEER REVIEWS AT THE END OF EACH SPRINT & COMMITS TO SENSITIVE CODE LIBRARIES

CHECKING EACH OTHER’S SOURCE CODE FOR POTENTIAL VULNERABILITIES

A manual peer review process is best incorporated into the Secure SDLC to ensure an efficient system. This can be a process where reviews are assigned randomly to engineers before code is promoted or committed. Code review tools such as Gerrit can be used by reviewers, along with merge requests and pull requests to highlight changes that are suggested. For high-risk code that performs security functions (e.g. authentication services, encryption modules, login and authorization services, session management components, etc.), this review process is critical. In order for this process to be effective as a compensating security control, it is important for engineers who carry out reviews to be fully trained in secure coding methodologies and secure coding practices in order to fully identify weak code that could potentially be exploited. Utilizing manual peer reviews is a security best practice that establishes separation of duties, prevents malicious code from entering production, and helps to mitigate malicious insider threats.

When conducting a security peer review, engineers should look for several critical factors in the source code, including ensuring that secure coding best practices are followed, and checking to determine whether backdoors, malicious code, privacy violations, or known vulnerabilities are present. Looking for language-specific vulnerabilities (e.g. possibilities for buffer overflows in C-based languages) is also important.

This best practice furthers the engineer's responsibility to produce secure code and continues to make engineers accountable for the quality and security of their code. Overall, conducting thorough security peer reviews in your business helps to establish and secure a culture of cybersecurity within your organization.

USING STATIC ANALYSIS TESTING DURING DEVELOPMENT NOT JUST AT THE END

STATIC ANALYSIS TESTING

Automated scanning tools are vital to ensuring data security, in addition to peer reviews and manual tests that are carried out in the development environment. That said, it is important to integrate nightly security scanning for use with nightly builds - in conjunction with accurate scanning rules - to catch many critical vulnerabilities. In order for such a practice to be used efficiently, scanners must be fine-tuned to eliminate as many false positives as possible, along with turning off low accuracy rules in order to carry out an accurate scan. This is significant since, at this point in the life cycle, engineers need to obtain critical information without being given noisy,

isn't pertinent to overall security. Thus, it is imperative to tune scanners to output useful information so as to not increase time-consumption on unnecessary tasks. It is also important to note the different engines and parameters that scanners use, the latter of which includes: keyword searches, binary analyses, data flow analyses, structural analyses, null pointer analyses, etc. With this in mind, correct scanner parameters need to be used in order to obtain the most accurate and relevant data.

AUTOMATED CODE ANALYSIS IN THIS PHASE UNCOVERS VULNERABILITIES EARLIER

While utilizing manual code reviews and testing is critical, using automated security testing during development can identify the most critical vulnerabilities that have plagued applications for decades – and continue to plague applications (e.g. SQL injection, Buffer Overflow, XSS, XSRF vulnerabilities) - before they reach code repositories. After the development phase, engineers move onto the verification & testing phase, which – when integrating security principles into the process – is a critical phase in the Secure SDLC. Speak to a Consultant About Building a Secure Development Phase

About

Cypress Data Defense was founded in 2013 and is headquartered in Denver, Colorado with offices across the United States. Our goal is to help organizations secure their IT development and operations using a pragmatic, risk-based approach. The diverse background of our founders allows us to apply security controls to governance, networks, and applications across the enterprise.

Latest Posts

How to Integrate Security Into a DevOps Cycle

However, DevOps processes aren't restricted to…

Secure SDLC and Best Practices for Outsourcing

A secure software development life cycle (SDLC…

10 Best Practices for Application Security in the Cloud

According to Gartner, the global cloud market will…

Contact

Cypress Data Defense

14143 Denver West Pkwy

Suite 100

Golden, CO 80401


PH: 720.588.8133


Email: info@cypressdatadefense.com


Social

© Cypress Data Defense, LLC | 2022 - All Rights Reserved