Elements of a secure development life-cycle

I love to code and have been doing it ever since I got my hands on a TRS-80 with its impressive 16K of RAM and 8-bit microprocessor in the mid ‘80s. Anyone up for a game of Cuthbert Goes Walkabout?

A lot has changed since then, but the things I love most about coding are still the same: solving tricky problems and getting to see your ideas come to life. One of my personal challenges is reining in my enthusiasm to see the end result, taking a deep breath, and making sure to do all the things along the way that make the difference between writing good code and writing awesome code.

That is especially important to do when thinking about cybersecurity. Granted, some of those things can be time consuming, and the truth is that they do add time and cost to development projects. But what is the cost of cutting corners? Sure, you may save a few dollars by skipping some steps, but with minimum ransomware demands being in the tens of thousands now, that’s hardly a bargain.

On a positive note, development teams are becoming aware of the need to weave cybersecurity into the development life-cycle, but it isn’t always clear what that entails, so here is a list of things for your organization to consider. This is by no means an exhaustive list, and if it seems like a lot to take on, remember that it doesn’t have to be all or nothing, starting with the basics and having a continuous improvement plan is a great way to begin.

People

  • Training: People are often the weak link when it comes to cybersecurity. Annual cyber awareness training has proven to be quite effective at reducing cybersecurity incidents, along with role-specific training to make sure your development team is up to date with the latest threats and best practices.
  • Leadership: Your cybersecurity program can only succeed if there is commitment across the organization and this starts at the top. Leaders need to be clear on their expectations and organizational objectives when it comes to cybersecurity.
  • Accountability: Objectives and expectations are meaningless without accountability. People must be aware of expectations and be held accountable for their actions (or inaction).
  • Response team: A security response team & process should be established that can quickly respond to threats or incidents when they do arise.

Process

  • Security requirements: When defining product requirements it is important to take the time to identify security requirements to make sure the solution and the information it processes are adequately protected.
  • Threat modelling: Applying a methodical process to identify potential threats and vulnerabilities is a necessary first step in ensuring there are adequate safeguards built into the solution.
  • Security design reviews: Designs need to be assessed from a security perspective to verify that the threats and risks have been appropriately factored in at the architecture & design level.
  • Secure coding: A secure coding policy or guidelines should be established and enforced to ensure that developers apply best practices during the implementation phase.
  • Code inspections: This practice has been around for a long time and is proven to reduce the number and severity of software defects. Developers should be trained on security best practices and ensure those are followed throughout the inspection process.
  • Security Testing: Test plans should have a category explicitly dedicated to security testing to ensure the application meets the defined security requirements and is free (to the extent possible) of defects that introduce security vulnerabilities.
  • External Dependencies: It should not be assumed that external components integrated into the application are secure. Third party software should be explicitly tracked on every release including knowing what version is in use and what known vulnerabilities are present by checking vulnerability databases.
  • Penetration testing: The last chance to identify vulnerabilities before releasing an application or software update is to engage a seasoned penetration tester to identify weaknesses that hackers will try to exploit.
  • Change management: There should be an established and enforced change management process to control what code is checked in, by whom and for what reason.
  • Patching: Despite best efforts, defects will happen and vulnerabilities will be discovered. There needs to be an established security patching and upgrade process to make sure vulnerabilities can be addressed in an efficient and timely manner.
  • Gates: The development process should include specific gates that are checked before the software is allowed to proceed from one stage to the next. For example, before and application or update can be released, development leaders should verify that there was a security design review, code inspections took place, security testing was performed and so on.
  • Automation: In order to minimize human error in the development process, a secure, repeatable & automated build/test/deployment process and infrastructure should be established and utilized.
  • Budget: When establishing a budget for the development organization or a particular project, there should be time and money allocated specifically for security in order to give the development team the necessary tools and resources.
  • Measurements: The performance of the secure development process needs to be measurable. This is done by establishing and tracking secure development process Key Performance Indicators such as compliance status per release, percentage of security test cases, number of major and critical vulnerabilities found during testing per release, number of security defects found during testing, number of security defects found in production to name a few. The information should be periodically analyzed and used to improve the process.
  • Audits: The security program and processed should be periodically audited to make sure expectations are understood, established policies and procedures are being properly applied and objectives are being met. This is not intended to be punitive, but rather to identify weaknesses in the secure development process and plan improvements.
  • Policies: Secure development policies need to be detailed and specific covering everything from the procedural elements of the secure development process all the way down to specific technical details such as approved tools, required compiler flags, acceptable crypto suites, etc.

Technology

  • Access control: Access to the software repository must be restricted to authenticated and authorized users only following the principle of least privilege to reduce the risk of accidental or malicious introduction of vulnerabilities into the source tree.
  • Repo scanning: The source code repository should be automatically scanned on a regular basis to identify vulnerabilities that may be present in third-party or in-house components.
  • Static code analysis: Static code analysis tools should be used to automatically check the code for issues such as buffer overflows, the use of insecure functions and libraries, etc.
  • Vulnerability scanning: Automated vulnerability scanning tools should be periodically used to identify any vulnerabilities that may have been discovered since the last scan. This can help quickly identify and mitigate vulnerabilities that are discovered over time.
  • Integrity protection: Mechanisms such as code signing should be used to verify the integrity of software releases, patches, upgrades or any component integrated with the application.
  • Compiler: Secure compiler settings should be identified, documented and enforced to prevent insecure code from introducing vulnerabilities.
  • Hardening: Endpoint hardening should be applied to all endpoints including developer systems, servers and infrastructure in both the development and production environments.
  • Monitoring: Security specific monitoring and alerting should be built into the application that can help identify anomalies that indicate an attack or breach once the system has been deployed.

If all of this seems daunting don’t be discouraged. It doesn’t all have to be done overnight and there are lots of free resources that can help. One of my favourites is the OWASP Cheat Sheet Series which provides an extensive list of well written cheat sheets covering many application security topics. Pick a few of the items from the list above that you think you will be able to implement in the next few months, and check out the cheat sheet series for resources that might help.

Posted in Uncategorized.

Leave a Reply

Your email address will not be published. Required fields are marked *