How to Reduce the Cost of Developing Your Software

We work with our clients to improve the security of their software. Most of the time this is through penetration testing (or pentesting); however, we often feel that we’re consulted too late in the development life cycle. Sometimes just before the product is released.

The result is, unfortunately, the identification of a large number of security vulnerabilities. This in turn results in expensive remediation work and more retesting. These ongoing cycles of pentesting, remediation and retesting can not only be expensive, but can often impact release deadlines.

If only there was a better way.…

The Quality Assurance movement

‘Quality Assurance’, or QA, isn't a new concept; it was born in the period following World War II.

W. Edwards Deming and Joseph Juran, the fathers of the ‘total quality’ movement, pitched their QA approach to Japanese businesses – applying quality control to the manufacturing process rather than simply inspecting products after the fact. In Japan, they embraced it with religious fervour. The U.S. didn't begin to embrace QA for another decade, allowing Japan to make huge advances in quality and gain a large market share, with its well-built cars, TVs, and computer chips.

In a nutshell, QA is a way of preventing mistakes or defects in manufactured products, and avoiding problems when delivering solutions or services to customers.

Taking traditional QA a step further

The advantage of early defect detection in software is well documented. Studies show that the cost of defect resolution increases by several orders of magnitude when identified after product release, when compared to defects identified during the early stages of the software development cycle.

For example, in an article in iSixSigma Magazine, Mukesh Soni quotes a report from IBM that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.

However, many ISO 9000 companies that successfully embrace QA are frequently surprised when a penetration test identifies a large number of security defects.

So why do the traditional QA concepts frequently fail to prevent security defects? The answer is simple: the developers do not truly understand how these security defects can be exploited and the impact they have on the system.

This is not surprising, as the exploitation of security defects is seen by some as a ‘dark art’. It’s often difficult to truly understand the impact of vulnerabilities such as Cross-Site Scripting (XSS), SQL Injection and Cross-Site Request Forgery (CSRF) unless you’re able to exploit them yourself.

Secure Software Development Life Cycle

The increasing concerns and business risks associated with insecure software have brought increased attention to the need to integrate security into the development process. By taking the lessons learnt from QA, and introducing security awareness at all phases of the development cycle, we can identify security vulnerability much earlier. Hence the Secure Software Development Life Cycle (Secure SDLC) was born.

Many software vendors embrace Secure SDLCs in one form or another. For example, Microsoft has a well-documented and established Microsoft Security Development Lifecycle (MS SDL). The table below shows a summary of the security practices Microsoft employs at each stage of their software development cycle.

Traditionally, pentesting consultancies have only been involved at the release stage where, unfortunately, it’s often too late to remediate findings without a significant impact on the project. We have found that by working with our partners at each stage of the development life cycle, they have experienced significant reduction in post release security vulnerabilities.

Experience has shown us that the greatest return on investment is gained on the pre-project training, sometimes referred to as Stage-0. That is, by training the project team on security before the project even starts.

Security means teaching your developers to hack

However, it’s one thing to explain to a team the importance of security, it’s another to teach the team to ‘hack’. We’ve found that when developers know how to exploit security defects, they truly understand the impact and risk to the rest of the system. Consequently, we find they start re-evaluating every line of code they write, as they write it, assessing the secure implications. What better way to prevent security defects than at the source, as the developers are typing the code?

This was how we came to create our own Secure Coding Workshop: a hands-on course where we teach developers to ‘hack’ common vulnerabilities themselves. We then turn the tables and get them to come up with solutions to resolve the problems they have just exploited, before turning the tables again to get them to hack their own remediation. Finally, we demonstrate the best practices of prevention.

This approach marries the problem and solution in the developers thought process, and ingrains the implications of core security issues. It makes them think like hackers, which makes them write more secure code.

Stage-0 security training won’t take away the need for pentesting. A good Secure SDLC will always include verification points at key stages of the project. However, it will dramatically reduce the unnecessary repeated cycle of remediation work and retests – what we could call your ‘technical debt’ – therefore reducing the cost of developing your software.

You can get more information on our Secure Coding Workshops here - our experts run classroom sessions at our Manchester HQ, but we'll also come to your premises.

Register for our Secure Coding Workshop

In the meantime, here's a list of software security soundbites...

10 Principles of Security Testing

The following basic principles from OWASP should be ingrained in all members of your development team ,to successfully integrate security into your Software Development Life Cycle.

1. There is No Silver Bullet

   There is no single solution to secure your software, no matter what your firewall/WAF/scanner vendor is telling you.

2. Think Strategically, Not Tactically

   It is not enough to simply fix reported bugs without further investigation into the root cause.

3. The SDLC is King

   Integrate security into each phase of your organisation's existing SDLC, to ensure a cost-effective and comprehensive security program.

4. Test Early and Test Often

   Bugs (security and functional) can be resolved faster and at a lower cost if they are detected early within the SDLC.

5. Understand the Scope of Security

   The effort to secure the system will vary depending on context. For example: a brochureware site has a lower risk profile than a Patient Medical Records System.

6. Nurture the Right Mindset

   Identifying security vulnerabilities requires ’thinking outside of the box‘. Normal test cases identify norm defects. It requires creativity to determine what unexpected data may expose security defects. Make no assumptions.

7. Use the Right Tools

   Utilise open source and commercial tools to automate routine security tasks. Just don’t rely purely on these tools (see 'There is no Silver Bullet').

8. The Devil is in the Detail

   There are no short cuts to securing an application. Do not rely on a single overall security review. Verify that every possible section of application logic has been tested, and that every use case scenario was explored for possible vulnerabilities.

9. Use Source Code When Available

   Provide security testers access to the source code while performing their review. This will provide the most cost-effective defect identification.

10. Develop Metrics

    Track the results of testing engagements and develop metrics that will measure the security defect trends within the organisation.

Feel free to reach out to one of our specialists at enquiries@secarma.co.uk