A Step-by-Step Guide to Secure Software Development

It’s a common practice among companies providing custom software development to disregard security issues at the early phases of software development lifecycle (SDLC). With such an approach, every succeeding phase inherits vulnerabilities of the previous one, and the final product cumulates multiple security breaches. As a result, your company will have to pay through the nose to close these breaches and enhance the software security in the future.

Best practices of secure software development suggest integrating security aspect into each phase of SDLC, from the requirement analysis to the maintenance, regardless of the project methodology, waterfall or agile.

A golden rule here is the earlier custom software providers integrate security aspect into an SDLC, the less money will be spent on fixing security vulnerabilities later on.

Custom software development: what it takes to be secure.

With this in mind, we’ve created a ready-to-go guide to secure software development stage by stage.

Requirement analysis stage

Requirements set a general guidance to the whole development process, so security control starts that early. The two points to keep in mind to ensure secure software development while working with customers’ requirements are:

  • Employ a combination of use and misuse cases.

The security consultants should foresee possible threats to the software and express them in misuse cases. Simultaneously, such cases should be covered by mitigation actions described in use cases.

Example:

A misuse case: An unauthorized user attempts to gain access to a customer’s application.

The corresponding use case: All such attempts should be logged and analyzed by a SIEM system.

  • Conduct security risk assessment and create a risk profile

When measuring security risks, follow the security guidelines from relevant authoritative sources, such as HIPAA and SOX In these, you’ll find additional requirements specific to your business domain to be addressed.

At requirement analysis stage, security specialists should provide business analysts, who create the project requirements, with the application’s risk profile. This document contains application surfaces that are sensitive to malicious attacks and security risks categorized by the severity level.

Design stage

Secure design stage involves six security principles to follow:

  • Least privilege. Software architecture should allow minimal user privileges for normal functioning.
  • Privilege separation. Specific actions in software (e.g., create, delete or modify certain properties) should be allowed to a limited number of users with higher privileges.
  • Complete mediation. Every user access to the software should be checked for authority. That decreases the chances of privilege escalation for a user with limited rights.
  • Multiple security layers. Applying this principle, you’ll eliminate the threat of a single point of security failure that will compromise the entire software. It’s simple math: the more defense layers your software has, the less are chances for a hacker to exploit its vulnerabilities.
  • Secure failure. In case your software ceases to operate, it should fail to a secure state. Although the software is not available anymore, still it should preserve confidentiality and integrity. So, make sure you’ve designed secure defaults that deny access, undo all the changes and restore the system to a secure state in case of emergency.
  • User-friendly security. Custom software design should incorporate security aspects in a way that doesn’t hinder UX. If security mechanisms in the software are obtrusive, users are likely to turn them off.

Development stage

Best practices of secure development defend software against high-risk vulnerabilities, including OWASP (Open Web Application Security Project) top 10. As a result, there will be no need in fixing such vulnerabilities later in the software life cycle, which decreases customer’s overhead and remediation costs.

OWASP, one of the most authoritative organizations in software security, provides a comprehensive checklist for secure coding practices. Use this source if you’re looking for exact requirements for secure software development, rather than for the descriptions of exploits.

Code review

Although secure coding practices mentioned above substantially decrease the number of software vulnerabilities, an additional layer of defense won’t go amiss. The code review stage should ensure the software security before it enters the production stage, where fixing vulnerabilities will cost a bundle.

Check OWASP’s security code review guide to understand the mechanics of reviewing code for certain vulnerabilities, and get the guidance on how to structure and execute the effort.

Testing stage. Penetration testing

Generally, the testing stage is focused on finding errors that don’t allow the application to work according to the customer’s requirements. It’s high time to check whether the developed product can handle possible security attacks by employing application penetration testing. This is the case when plenty is no plague. The operation should be performed in every build. Here, to drive down the cost, opt for automated penetration tests that will scan each build according to the same scenario to fish out the most critical vulnerabilities.

In addition, exploratory pentesting should be performed in every iteration of secure software development lifecycle when the application enters the release stage. In this case, pentesters don’t look for specific vulnerabilities. Instead, relying on their experience and intuition, engineers check the system for potential security defects.

It’s worth mentioning, that the personnel performing the testing should be trained on software attack methods and have the understanding of the software being developed.

Production and post-production stages

The software is ready to be installed on the production system, but the process of secure software development isn’t finished yet. Microsoft offers a set of practices to stick to after the product has finally seen the light:

  • Create an incidence response plan to address new threats. Identify appropriate security emergency contacts, establish security servicing plans for the third-party code and the code inherited from other groups within the organization.
  • Conduct ultimate security review. It may uncover vulnerabilities missed during the previous checks. The final review should verify that all misuse cases and security risks defined at the requirement analysis stage were addressed.
  • Certify and Archive the final product. Certifying helps to make sure that all the requirements to the software are met. Archiving, in its turn, helps to perform further maintenance operations.
  • Be prepared to execute incidence response plan. Of course, all custom software vendors hope that the moment of incidence response will never come. Still, to uphold their good name, software development companies should be ready to swiftly implement the incidence response plan, should the product experience any security breach.

Security cost

Undoubtedly, proper secure software development requires additional expenses and intensive involvement of security specialists. Still, it’s not rocket science, if implemented consistently, stage by stage. The additional cost of security in custom software development is not so high. Its integral parts are security aspect awareness of each team’s member and additional testing throughout the software development process.

Need to deal with a challenge in software planning, development or maintenance? Leverage the qualified assistance of our specialists to get the results you aspire to. 

Ask the Author

Sending the message ...

0/511

Sharing Information

In compliance with GDPR, your personal information will be collected and stored for five years on servers located in the Untied States. After this term is expired, your information will be erased. We will share your information with our development center, located at 2 Leanida Biady str., Minsk, Belarus, where it will be processed. At our headquarters and our development center we apply the same level of care in respect of your information as prescribed with GDPR rules. For more information, please refer to our Privacy PolicyYou may request erasing or updating your personal information here.