Secure Development – Part 1

Secure Development – Part 1
Arnie Raju

This is the first in a series of articles the team at The Solution Collective will be publishing on the subject of Secure Application Development. More and more of our clients are asking us about how to secure their information systems, but in reality it is a question that all our clients should be asking us – such is its importance!

In this post we will set the context for Secure Application Development, explain what it is, why it is important, and cover some high level actions that can be taken.  Ultimately Secure Application Development is an ongoing journey of education, discovery, and improvement – and as such subsequent posts will deep dive into specific areas of interest.

Technology and vulnerabilities

Bad Guy LemonTechnological progress continues to move forward at a breathtakingly rapid pace.  Our content is accessible remotely, it integrates with external systems, and is increasing in volume, importance and sensitivity.

Following right behind the positive progress are the vulnerabilities introduced with the new technology.  With these vulnerabilities come people looking to exploit them and access our information.  Script kiddies, hobby hackers, or more sinister characters – hackers from organised crime gangs or state sponsored agencies – intent on stealing our information, our identities and causing disruption, damage and general mayhem.

This exploitation of vulnerabilities can take many forms, but includes such methods as:

  • using vulnerabilities and backdoors intentionally but secretly created by technology firms in their software at the request of (or under extreme pressure from) security agencies
  • denial of service attacks, including distributed denial of service attacks from botnets
  • scanning for and attacking vulnerabilities in unpatched hardware and software, or exploiting zero-day vulnerabilities that have no available patches
  • using social engineering techniques such as phishing, whale-phishing, and simple phone calls to gain access to software systems

Exploits and consequences!

The consequences of an exploited software vulnerability are potentially limited only by the imagination of the bad actor – and for critical systems such as nuclear power station cooling pumps, I’m sure Jack Bauer would have a thing or two to say about insecure software development.  Even for seemingly ‘trivial’ software systems, the consequences can be very large.

  • The damage to data or infrastructure can have direct financial costs associated, but even if not – it can certainly have an effect on how efficiently a business can conduct its core activities.
  • The cost to investigate and repair or cleanup after a breach can be enormous.  Think of all the labour efforts involved with root cause analysis, reporting, enquiries and attempting to remediate a breach.
  • There can be a direct cost to company in terms of stolen money, or direct operating costs where computational power has been stolen from servers (e.g. bitcoin hashing).
  • Extortion of a person or business as a result of the information obtained during a breach.
  • Financial or even physical risk from exposing personally identifiable information
  • The bad press (reputational damage) surrounding a security breach can potentially larger than the direct consequences of the hack itself, particularly if the reputation of the company or organisation is built on trust

Whatever the nature of the attack, it is almost certainly going to cost the organisation money (either directly, or indirectly) – and it may have a serious impact on people’s lives.  People have lost their jobs, and in some cases their lives as a direct consequence of security breaches.

Traditional Software Development

The majority of software projects use a fairly traditional approach to development where a flavour of the Software Development Lifecycle is followed.  Requirements are gathered, architecture is agreed, design is documented, development is… yada, yada, yada…

In most cases, security and privacy assurance is treated as an gateway activity (or hurdle) once the development is complete and sign-off is needed for go-live from the business, and sometimes the security team (but often not at all).

This leaves resolution of vulnerabilities at the end of the development cycle – as an afterthought 🙁  Depending on the what the vulnerability is, where it is located and the risk it poses, providing a fix at this stage of the development lifecycle could be a costly one.

Worse still the application needs to meet an important dead-line and this activity is rushed through, the vulnerability is not picked up, the application is shipped, and then becomes the target of a organised team of un-ethical* hackers!!  (or worse still, after the issues has occured – very costly)

* there are good hackers too!

Rolling the dice…

It is certainly possible for an organisation to successfully develop secure applications using a traditional approach to software development, but in these cases you are generally relying on a single person, or team to do the right thing.

If that person leaves, the team changes, there is a change in technology, or there is external pressure to speed things and cut corners – there is a good chance that the quality of the software will suffer.

The reality is secure development is too great a responsibility for a single person or team to handle – in terms of workload, knowledge and support needed from the organisation.

A secure system can very quickly become insecure…

  • Any customisation to a software system has the potential to introduce or expose vulnerabilities
  • Even inaction can sometimes introduce or expose vulnerabilities
  • Cost of securing a software system as an afterthought is likely to be higher than designing it from the start
  • Cost of securing a software system after an incident is likely to be much MUCH higher

Hoping that things are going to be secure without doing anything formally is as good as playing a game of roulette!

So what can we do? Enter stage right Secure Development Practice!

Secure Development Practice

What is it?

Secure Development Practice is the adoption secure development activities throughout the course of the software development lifecycle, with the goal of reducing risk or increasing assurance in an application.

It is about taking a security first approach to development, making it deliberate and ongoing – not just an afterthought.

Building secure software is the responsibility of all the stakeholders involved with the software development lifecycle (SDLC).  The technology and process alone does not a secure application make, culture is crucial in application security.

Methodologies, models and frameworks

Where the rubber hits the road.  There are a great number of secure development activities that can (and in some cases should) be adopted, ranging from gathering security and data sensitivity requirements, through to penetration testing and application monitoring.
Subverting security

Some of these practices may already be in place, but in isolation they may only provide small gains in assurance –  where the investment in Secure Development Practices really starts to pay dividends is when they are incorporated as part of the full development lifecycle.

As beautifully illustrated in the image above, islands of security can sometimes be worse than no security at all – as they cost money and engender an atmosphere of false confidence.


Open Web Application Security Project (OWASP)

The Open Web Application Security Project or OWASP as it is commonly known, provides a Software Assurance Maturity Model (SAMM) – which is an open framework to help organisations formulate and implement a strategy for software security that is tailored to specific risks facing the organisation.  This model is built around critical business functions – governance, construction, verification and deployment.

Microsoft Security Development Lifecycle (SDL)

Over time, a number of large organisations such as Microsoft and VMWare have formulated their own secure development practices.  These practices provide structure and prescriptive activities to be followed at various stages of the SDLC when approaching software development within the organisation.

Microsoft’s process, the Security Development Lifecycle (SDL) is a security assurance process that focuses on software development and privacy throughout all phases of the development process.  This is treated as a living breathing process, with ongoing review and improvement to ensure it is relevant and effective

How can we do it?

So we know there is room for improvement, continuous improvement at that.  We have an idea of what we should be doing – but the burning question is how do we get there?

If taking the Microsoft SDL approach, there are a collection of security activities that require implementation across a number of phases of development lifecycle (and one preceding it).  The phases being:

  • Training
  • Requirements and Design
  • Implementation
  • Verification
  • Release and response.

The mandated activities include such things as security requirements, creation of quality gates, risk assessments and threat modelling (to be covered in more depth in later articles).

At first glance you may be intimidated by the sheer number of activities there are to implement, but the thing to keep front of mind is that you don’t take this on all at once.

This is where Microsoft’s SDL Optimisation model may come in handy to help set a road-map to secure development within your organisation.  The model will provide guidance from very basic levels of secure development maturity, right through to being fully compliant

Implementation of secure development is as much about a cultural change as it is implementation of a processes.

It won’t happen overnight, but it will happen – if you want it to!

Key take-aways

Technology is swiss cheese when it comes to vulnerabilities, generally speaking that is.

Traditional SDLC is not enough to ensure you have a secure application

Invest in your people, education is key – people don’t know what they don’t know, and once they are aware of the gaps in their knowledge they will then need to learn the new stuff they don’t know

Not just the developers – responsibility for the development of secure applications does not just lie on the shoulders of developers.

Take baby steps – there is a lot to take in, implementation of SDP can be overwhelming.  Align your priorities with your organisation’s maturity and take baby steps.


Introduction to the Secure Software Development Lifecycle

Open Web Application Security Project

Explore Open Secure Application Maturity Model”>”>

Microsoft Secure Development Lifecycle Training

Microsoft Secure Development Lifecycle Starter Kit

Massive Security Breach At Sony — Here’s What You Need To Know

Security Development Lifecycle: A Living Process