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.
Developing software in today's IT corporate landscape is a complex process that can be broken down into several phases. These phases can be defined by different methodologies & models utilized by software engineers. The steps of the development process are defined as the Software Development Life Cycle (SDLC). This lifecycle of application development is usually comprised of four to six phases, namely:
Planning & Requirements • Architecture and Design • Test Planning • Coding • Testing & Results • Release & Maintenance
• Security Training - Core Security as well as Specialized and ongoing training for all project team members throughout the project.
There are several traditional software development models that engineers utilize for developing software including, Waterfall, Agile, Scrum, and DevOps. Each of these models have various benefits and challenges.
• The Waterfall model is a linear, step-by-step, sequential development strategy with a top-down approach and specific goals for each phase, allowing for easier management and departmentalization.
• In contrast, Agile is a more collaborative model that has teams build modules in increments after a basic initial design is determined. It’s then followed by evaluations and more module development. Scrum is included in the Agile model.
• DevOps seeks to create collaboration among IT silos so that QA teams, software developers and operations admins/engineers work together throughout the SDLC.
Traditional SDLC models do not include security testing or secure coding into their methodologies or phases. Because of this, security is often an afterthought during the build process. The disconnect between management and the actual developers can be vast when it comes to application security. In addition, only 11 percent of developers believe that their organization has a fully-deployed security training program for their personnel. This results in security flaws in many software applications - flaws that are only identified near the end of the software development lifecycle (usually the testing or release phase), and are very difficult and expensive to remediate.
Many IT firms do not have a large budget for security, or don’t make it a priority. Often times corporations take the approach of simply reacting to security vulnerabilities (as opposed to proactively testing for them) after the application has been developed and flaws have been found - either by personnel, researchers, end-users, or by hackers. For the former (personnel) - since testing usually occurs near the end of the SDLC - costs and timelines often do not allow businesses to go back and remediate the developed software. Security flaws that are found late in the SDLC are allowed to stay, since quickly-developed, functional applications are often top priority for the sake of revenue and sales. The alternative is a security
quick fix, which often results in the accumulation of technical debt being added at the end of the development process to partly mitigate security flaws. The result is an insecure product being deployed and sent to end-users.
A perfect analogy can be seen with the car manufacturing industry. At the assembly line, quality assurance checks, performance checks, and safety checks are conducted at every checkpoint in the process. The same ideas should be in place as it comes to security in development.
DevOps seeks to create collaboration among IT silos so that QA teams, software developers and operations admins/engineers work together throughout the SDLC. It is important to note that traditional SDLC models do not include security testing or secure coding into their methodologies or phases. Deploying software without consistently checking for security flaws at every phase in the SDLC is like sending a new car out to a car dealer for sale without having run any safety checks on it.
The Secure Software Development Life Cycle (Secure SDLC or SSDLC) incorporates security at every stage. This methodology also includes the use of secure coding techniques. Security is not just a goal, but a core concept that is implemented into the blueprint and architecture of the software at each step.
Adding Security into the SDLC is imperative as it includes small and important features in the software. It’s determined on a continuous and constant basis by collaborations between developers, operations admins, and security engineers.
By implementing and testing security throughout development, companies are able to allocate resources to future projects, rather than going back and fixing costly errors. Without security built-in from the project conception, there is a window of opportunity for cyber-criminals to breach an application's defenses.
Defenders have limited time and resources in their pursuit of discovering vulnerabilities, so must hardening applications as much as possible during development is critical. Contrary to this, cyber-criminals often have unlimited time and tools to scan, probe, and penetrate an application in order to exploit it, needing only one security hole to succeed. Attackers often win in this scenario, which leaves businesses with the high risk of being subject to data breaches.
At Cypress Data Defense, our goal is to help your organization integrate security into all phases of software development. We begin the Secure Development Life Cycle process by educating developers and executives, while also raising security awareness within organizations. We perform threat modeling, write security abuse cases, and conduct security tests during the requirements and planning phases. We utilize automated security scanners during the development and verification phases. We also build and utilize post-production security monitoring systems after release. In completing the feedback loop between development and operations, our work allows critical security information to become visible to everyone on the project team.
The important takeaway is that every point in the SSDLC has security at its core, and every point in the development process creates a possibility - and opportunity - to find a critical flaw that a traditional SDLC may not discover until it is too late.