Secure SDLC best practices

The traditional software development life cycle (SDLC) is geared towards meeting requirements in terms of functions and features, usually to fulfill some specified business objective. However, the set of activities during the different phases of the SDLC might not always intrinsically measure up to security standards.

This can be addressed by incorporating a security layer within the SDLC, embedding security right from the beginning of the development cycle. The idea is to have security built in rather than bolted on, maintaining the security paradigm during every phase, to ensure a secure SDLC.

Phase 1: Requirements gathering and analysis

The software development process typically starts with requirements gathering and systems analysis, the results of which are then used to create the design. The business analysts and other personnel putting together requirements and functional specifications need to be clued in to security needs, or better still, someone who understands security from a product life cycle perspective should be on the team.

• 

• During requirements gathering for a secure SDLC, the first step is to identify applicable policies and standards and the mandates that the software will need to follow; compliance is an important factor to incorporate a standard framework, as well as to ensure audit requirements are met. Next, the compliance requirements can be mapped to the security controls.

  This is followed up by developing a confidentiality, integrity and availability (CIA) matrix that helps define the foundation of security controls, and is instrumental in creating a secure software design. At this point security ’toll gates‘ are set, which are essentially criteria that need to be met for the project to move on to the coding phase.

  Phase 2: Design

  An architectural blueprint is now created, taking all the security requirements into consideration. This defines the entry and exit points in addition to defining how the business logic would interact with the different layers of the software.

  In keeping with the secure SDLC paradigm, threat modeling is performed, which puts the software through various scenarios of misuse to assess the security robustness. In the process, various avenues to tackle potential problems emerge. One must keep in mind that the application communicates in a distributed environment rather than just a single system.

  Phase 3: Coding

  The best practices in the coding phase of a secure SDLC revolve around educating the developers. Instead of focusing only on language- or platform-specific problems, developers need an insight into how security vulnerabilities are created. These include not just technical vulnerabilities, but also problems from a business logic perspective.

  It is necessary to establish secure coding practices among developers through guidelines and awareness campaigns. A source code review helps in making sure the coding quality is maintained, in addition to meeting secure coding standards. Organizations can also procure automatic code review tools to ensure security.

  Phase 4: Quality assurance

  The three pillars of quality are performance, functionality and security. Without embedded security, the quality of the software is questionable, thus making security a de facto quality vector. Tools to measure technical vulnerabilities are all very well, but the human factor cannot be underestimated, especially when it comes to business logic.

  For a secure SDLC, outsourcing of software testing is a good idea, for cost savings definitely, but more so to leverage the specialized testing knowledge, skills and experience of the experts in the company being outsourced to.

  When outsourcing, legalities like data sensitivity must be considered, and access to production databases should be avoided. Data should be masked or sanitized and the scope of the testing pre-defined.

  Phase 5: Deployment

  In the final deployment phase of a secure SDLC, the different components of the platform interact with each other. Platform security cannot be ignored, for while the application itself might be secure, the platform it operates on might have exploitable flaws. Platforms thus need to be made secure by turning off unwanted services, running the machines on the least privilege principle, and making sure there are security safeguards such as IDS, firewalls, and so on.

  Development, as the very name suggests, is an on-going process. Updates, patches and enhancements to the application code are constantly required. It is a cycle that repeats itself, but security, even at the time of these modifications, must always be in focus to ensure a robust and secure SDLC.

  ---

  About the author: Puneet Mehta is the co-chair of OWASP India, as well as the co-founder and director of OWASP's Delhi Chapter. Mehta is a frequent contributor to TechTarget. He has authored many articles, as well as been quoted in national and international media. Mehta's focus areas include information security, risk management and vulnerability research.

  (As told to Varun Haran)