Your journey towards secure development

This article focuses on understanding web security risks and building the foundations for secure development. This is a large subject area that I will look to address across a number of articles.

It’s important to integrate secure practices into your software development lifecycle. Even with a strong defence in depth approach to security, poor coding practices will leave you susceptible to compromise. Hardened server builds and Web Application Firewalls (WAF) won’t provide complete protection if your applications are insecure. These should be seen as a supplement to and not replacement for secure coding.

There are numerous vulnerabilities that a WAF isn't going to protect you against such as:

• Script injection (i.e. Magecart type attacks);
• Concurrency (multiple concurrent user session) flaws;
• Business logic flaws.

As we become increasingly reliant on software in our every day lives the importance of maintaining the confidentiality of our data as well as the integrity of transactions is of paramount importance.

Understand security risks to applications

For web applications the OWASP top 10 is a great place to build your understanding of the most critical security risks to web applications. As at the time of writing this article we’re on the 2017 version. This list is maintained by OWASP to ensure it remains reflective of the latest security risks. Even with these updates there are common flaws that are repeated across the versions. Despite being widely documented with proven mitigations the likes of SQL injection and Cross-Site Scripting (XSS) flaws remain prevalent across today's web applications. OWASP is a great resource to not only understand the risks but to also understand how to code securely and perform effective security testing.

There are a wealth of readily available resources. The CWE/SANS TOP 25 Most Dangerous Software Errors is another useful resource to refer to.

If you lack formal company security standards a decent place to start is to require mitigation of the OWASP Top 10 or CWE / SANS Top 25 vulnerabilities within both your internal teams or third parties via Service Level Agreements (SLAs).

A word of note from experience. Just because your company is outsourcing to a experienced software development company don’t assume that good secure coding practices will be followed. Expect to be delivered a minimum viable product (MVP) as companies look to reduce costs and maximise profits. Make sure your security standards are included in that minimum. Trying to include these in retrospect after an initial contract is agreed is often far from straightforward. Typical challenges may include:

• Renegotiating a new contract / service agreement - in large organisations this can be particularly onerous. I've been involved in these situations that take in excess of 6 months to resolve;
• The individual who is accountable for the third party may have limited motivation to instigate or oversee delivery of the changes;
• It can be costly even if your company has negotiated decent rates for services, changes to those services often come at a premium.

Secure Software Development Framework (SSDF)

Having spent a considerable period of time working in development I’ve seen and been involved in development practices of wide variations in maturity. Take my word for it that poor development / change management practices are not just limited to small businesses!

It doesn’t matter what your current level of maturity is. The key is to understand your current state and desired state. You’ll then want to define a program to enable transformation (through delivery of milestones) to your desired state.

A good place to start is with reviewing your existing processes against the Capability Maturity Model Integration (CMMI). You need to understand what you have and its current state of maturity before you can look to make improvements.

There are a wealth of resources available providing detail on what your desired state might look like. The OWASP Software Assurance Maturity Model (SAMM) supports the complete software development lifecycle and covers key categories. For each category there are 3 maturity levels provided helping you get started and understand a path of progression. This is comprehensive covering categories from Threat Assessment through to Education and Guidance.

There are various alternatives to consider such as:

• Building Security in Maturity Model (BSIMM);
• Microsoft, Security Development Lifecycle;
• CMMI Development.

A framework helps to identify the categories you should consider and enables you to take a structured approach to modelling what you have and determining where you want to be. These frameworks will need to be tailored to your organisations. There is no mandate that you need to achieve the highest maturity ratings across all the categories. You’ll need to consider what fits within the appetite of your organisation to understand what levels of maturity will meet your needs.

NIST have released an interesting paper covering how to mitigate risk of software vulnerabilities by adopting a SSDF. This is a comprehensive resource about this topic and well worth a read.

Final Thought

When developing secure development practices it is vital to understand the type of vulnerabilities you’ll need to address. Good coding standards combined with vulnerability mitigation's (bespoke or part of a framework) will make substantial improvements to the security posture of your applications.

As the security maturity of your development practices improve you’ll see a drop in the number of vulnerabilities being identified in your production systems through automated vulnerability scanning and penetration testing. This will reduce the potential risk of compromise to your applications and lower the cost of remediation as they are addressed earlier in the lifecycle.

Be proactive in your approach and not reactive:

• Proactive - avoid vulnerabilities or fix early in the lifecycle;
• Reactive - playing whack a mole with a multitude of vulnerabilities in production. Being in a constant cycle of dealing with the issues rather than seeking to address the root cause of the problem.

It doesn’t matter where you are on your own security journey, every company is at a varying level of maturity. You just need to understand where you currently are and where you are trying to get to. There is no better time than the present to get started!

I’ll be looking to create a series of security in development related articles to cover some other important topics. It would be great to get your thoughts on the topics covered along with any experiences that you’ve had that can be of help to others.