Security in Software Development Lifecycle
Security in software Development
Welcome to the last, but not the least, module of the software security-testing workshop. So far, we have discussed how you can perform code review, how to use code review tools and methodologies along with types of the code reviews. We have also learned that security should be built into the software development lifecycle. It’s worthwhile to present the concept of security during the development lifecycle.
In this module, we will be highlighting the security development lifecycle and we recommend that you should first complete the previous four modules.
What is security in the software development lifecycle?
Well, this is basically building security within the software development stages into the software itself. A security development lifecycle is a process that helps software developers to build software with security consideration.
What needs to be considered as security measures have been listed below as the experience from the industry best practices.
• Security should be considered at design time
• Should have specific requirements for security
• Perform risk assessments
• Quality assurance of code
• Only used approved tools
• Don’t use unsafe functions
• Perform code reviews
Including the above measures, there is a set methodology given by Microsoft for security development, as shown in below figure.
This methodology is well set and used by software developers widely, especially developers who are inclined to use a Microsoft platform. It has 17 SDL practice areas, which we have listed below, however, we have made no change to the content.
• SDL Practice #1: Core Security Training
• SDL Practice #2: Establish Security and Privacy Requirements
• SDL Practice #3: Create Quality Gates/Bug Bars
• SDL Practice #4: Perform Security and Privacy Risk Assessments
• SDL Practice #5: Establish Design Requirements
• SDL Practice #6: Perform Attack Surface Analysis/Reduction
• SDL Practice #7: Use Threat Modeling
• SDL Practice #8: Use Approved Tools
• SDL Practice #9: Deprecate Unsafe Functions
• SDL Practice #10: Perform Static Analysis
• SDL Practice #11: Perform Dynamic Analysis
• SDL Practice #12: Perform Fuzz Testing
• SDL Practice #13: Conduct Attack Surface Review
• SDL Practice #14: Create an Incident Response Plan
• SDL Practice #15: Conduct Final Security Review
• SDL Practice #16: Certify Release and Archive
• SDL Practice #17: Execute Incident Response Plan
These practice areas have been divided into even phases as shown above in the figure. For complete study of the software development lifecycle please visit vendor site http://www.microsoft.com/ security/sdl/default.aspx.
However, along with and on top of these practice areas, you need a much broader approach and also cover the following:
• Adopt an activity driven approach
• Document security activities derived by best practices
• Define dependencies and prerequisites
• Define entry scenarios for activities
• Define strategic and tactical tracks for activities
• Define roadmaps for software security
Industry Facts
The Blackhat community presents a security-enhancing process covering Microsoft security lifecycle, as well, as shown in below figure.
It is said that a fool with a tool is still a fool, so no matter what methodologies and tools you are using to secure your software, you should keep in mind that it’s YOU who will be securing your software. In summary, what industry highlights is that you should follow and adopt a formal process to build security into the software development lifecycle SDLC and should have a plan for implementation.
It’s said “to design, build, and deploy secure applications, you must integrate security into your application development life cycle and adapt your current software engineering practices and methodologies to include specific security-related activities.”
In order to effectively build and manage security within software, industry experts have created a set of questions that should be considered. These questions form a good basis for shaping the risk management activities and validations that will be associated with each phase of the software life cycle.
• How are security stakeholders identified? How are their interests understood?
• How are threats that concern stakeholders identified, assessed, prioritized for the software?
• How is the design verified to satisfy its security objectives and requirements?
• How is the design proven to be “good enough”, i.e., free of exploitable faults and other weaknesses?
• How is the code proven faithful to the design?
• How is the code proven to be “good enough”, i.e., free of exploitable faults and other weaknesses?
• How are threats and vulnerabilities weighed against risks to the business/mission and stakeholders?
• How are attacks identified and handled?
This is a huge topic and we have presented a summary of what is available in common in the software security industry in order to protect the software code from threats and maintain the security from end to end. We hope we deliver knowledge in a nutshell.