Insights
Blaze Info Sec
Published
Share

Moving Security to the Left? Security assurance in software development methodologies

By Blaze Information Security

The traditional penetration test model is applied by most organizations out there, but it is far from ideal. When thinking of systems, there is a problematic approach to security in the traditional model. This process is like that of baking a cake. If you think of your system as a cake, security could be considered as the icing or the cherry on top. This means that security is not baked into the foundations of the cake as layers but rather just brushed on to give it a final touch. This attempt to retrofit security into a system that was never designed with it in the first place usually creates a system that is insufficiently secure and will bring a lot more costs at the end of the day.

Traditional security testing has been happening since around the 1960s. The idea of actually testing systems to ensure their integrity began when the US Air Force first identified systems’ security was a serious threat. The penetrate-and-patch approach evolved into its current shape and form all the way to the 1990s, when the first IT security companies started to appear in the market to perform penetration testing for customer organizations. And to be honest, not much has changed since then. That means that for almost 30 years organizations have been doing the same thing.

In the past decade or so there has been a shift from the traditional software development model, known as Waterfall, to the Agile development approach. Many modern organizations made this shift to maintain a focus on the rapid delivery of business value. The methodologies used in Agile project management all follow the Agile Manifesto that is based on continuous improvement, flexibility, input of the team, and the delivery of high-quality results. But just like in the traditional project models, security has taken the back-seat and is rarely considered a priority.

This causes several disadvantages. Firstly, as security assessments are usually time boxed, ranging from a few days to a few weeks, it makes it difficult for the penetration tester to get acquainted with the inner workings of the systems, fully understanding the business logic etc., making it challenging to find the best bugs in a limited amount of time. Secondly, and more concretely, the later the vulnerabilities are detected the harder it is to fix them. Correcting security flaws just before releasing the product is way more expensive than if they had been discovered at the early design phases. This will cost more man hours but also delay time to market. According to US National Institute of Standards and Technology, NIST, it can cost up to 30 times MORE to fix issues at the very end of the development process than at the beginning.

What could organizations do to avoid these disadvantages?

First of all, modern security engineering practices should be built into the system. It should be part of the ingredients and baked in as layers. Security-related tasks should be an active part of all the project sprints. In an ideal world this could be done by including the following to development projects:

  • Secure coding training for developers.
  • General security consultancy in terms of best practices and security review of requirements and architecture.
  • Risk analysis and threat modeling activities would be included in each sprint. 
 Source code security review of code done on a regular basis.
  • A robust DevSecOps pipeline with open-source and proprietary tools would be included in the organization.
  • Penetration testing for every major release.

Now, this can be an overwhelming change to do in a limited timeframe with limited resources, but there are several activities that can be added into the development process to make this possible, even with a limited budget.

  • Security requirements and abuse cases can be made part of the very first stage of the development process. One good way to do this is to add “adversarial thinking” or “evil user stories” which can bring a security thinking into the project and raise awareness of all developers.
  • Another good option would be to add a “security champion” to the team. This person would be a member of the team who is more familiar with security and will serve as an interface with the security team, if it exists.
  • Add open-source security controls into your DevOps pipeline.
  • Also, involvement of internal or external security experts in all design phases is recommended to increase expertise in the whole team.

These shifts will make developers able to test a variety of security issues and learn how to remediate them. By shifting security validations to the left, organizations can guarantee  time to market and save large amounts of money.


Blaze Info Sec

Blaze Information Security is a privately held, independent information security firm with offices in Brazil and Portugal. It serves a variety of industries including banking and finance, and fintech.

Share this Article
Related Insights
Featured
Holland Fintech Digital Transformation Paper 2024
Holland Fintech is proud to present the Digital Transformation Paper 2024. This whitepaper, led by the Holland Fintech working group Digital Transformation in collaboration with Accenture, provides valuable insights into the dynamics and key factors influencing successful collaborations between fintechs and incumbents.
Holland Fintech Pavilion at Money 20/20
Money 20/20 – Join our Pavilion! The Holland Fintech Pavilion offers a unique opportunity to connect with a global audience of fintech professionals. Located at the heart of Money 20/20, the pavilion provides a central hub for networking, collaboration, and exposure.
Amsterdam Fintech Week
Amsterdam FinTech Week is back on 2-4 October 2024! Be a sponsor, co-organizer, or just participate in our community events.

How likely are you to recommend Holland FinTech?