Secure Software Development Lifecycle

This post talks about aligning security within software development lifecycle in order to produce more robust applications with less vulnerabilities. This alignment is considered to be a strategic action as its benefit will remain for long-term.

We can achieve secure SDLC by adding a security checkpoints through the process of software delivery and this will be independent of the methodology as it is Waterfall or Agile or others.

If you would like to implement secure development lifecycle, partially or fully, in your organization I would be happy to help and share my experience.

Why Secure Development Lifecycle?

One important aspects in vulnerability management is to discover and close vulnerabilities as early as possible. In the context of applications, the earliest point to discover a vulnerability is during the development. The main objective of having a secure development lifecycle (SDL) is to eliminate application vulnerabilities or security bugs.  Another aspect is that security (reliability) is one dimension of software quality and a lot of companies mandate to have SDL for in-house developed applications, outsourced applications and off-the-shelf solutions.

Why Security in Applications?

For hackers, with or without intention, the application will be the main door to interact with the targeted organization. This makes it crucial to have an attack-proof applications. However, having a secure application alone is not enough as we need to secure all application dependencies including the network, the OS, the platform, the framework, the libraries and the browser (for web-applications).

In general, security has three pillars: Confidentiality, Integrity and Availability (CIA). However, in term of application security we add also Authentication, Authorization and Accountability (AAA). For legal requirements we go an extra step and add non-repudiation in our applications.

SDL Phases

1- Requirement Analysis Phase

In the requirements phase we  carry high-level risk assessment with the goal of identifying security requirements.

Example: The company wants to develop an internal Java based application that process employees information. As security checkpoint in this phase, we require a login page as entry page for this application and better to integrate with Active Directory to achieve SSO.

2- Design Phase

Here we focus on achieving “Secure By Design” label to our software. This can be done through Threat Modeling so that we can identify our threats for the proposed software design and implement the required controls as response. Microsoft has developed a good methodology called STRIDE and free tool is available: Microsoft Threat Modeling Tool.

Example: The same previous application, we identify the sniffing as potential threat (Information Disclosure in STRIDE). As security checkpoint in this phase, we require the LDAP integration with AD should be SASL/DIGEST-MD5 and not Simple.

3- Build Phase

In this phase, we want to achieve “Built-in Security” by writing a secure code practice, avoid vulnerable components and use builtin security controls of operating system, browser…etc.

Enablers in this phase includes:

– Approved list of libraries
– Source Code Security Analyzer (SAST)

Example: We use the controls provided by browsers like: HTTPOnly and Secure Flags for cookies, XSS Protection…etc.

4- Testing Phase

Along with the UAT, we carry security testing to make sure security requirements are implemented and to make sure the application secure against known attack vectors.

Enablers in this phase includes:

– Penetration Test
– Fault-injection Test / Fuzzing

5- Deployment Phase

Secure deployment process is implemented to make sure that the same approved build is installed in the production with the approved secure configurations.