Security By Design – The Development Paradigm

In our ‘always on’ world, companies are increasingly challenged with delivering their services through technology which meets the customer needs but do so in a way that is secure and retains our privacy. If the headlines are to be believed, it’s an increasingly difficult balance to achieve. 

This reflects the drivers of speed to market and growth in new customers, market share, revenue or profit to drive growth heads the list of priorities. This rapidity and convenience is necessary for many to support return on investment and securing investment which is not always an easy bedfellow with security and privacy.

Breach-after-breach we see everyone from the travel & leisure industry to the financial sector falling victim to cybercrime and data breaches. The challenges are exponential, as our use of technology and desire to create and access our data when and where ever we are, increases. But despite the billions of devices, and software applications that exist, it may surprise you to learn that I believe there is a common flaw that, if addressed correctly could help vastly reduce our risks and exposure.

The bottom line is; Our approach to development and security needs to improve.

History in Development

I started out in IT over 35 years ago as a developer. At the time I had to learn a number of things, namely; FORTRAN, Pascal, Cobol, C, C+ and C++. It would seem obvious that I had to learn programming languages, but one thing which linked all of these things was, that memory and processing power was at a premium. Code had to be ‘slick’ i.e. every routine and sub-routine had to be coded in a way to minimise taking up unnecessary CPU cycles or memory (I started programming on ZX81 which came with 1 KB!).

As a developer my role was to create efficient code that met my core objectives. When I started working in companies that had PCs (Inel286 chips) the focus was still on efficiency of code, as was functionality. As I recall, Security was not a primary concern.

Back to the future

In the 90’s we started to see organisations utilising ‘Cloud’ technology which meant the cost of hardware and processing power came within reach of everyone. Start-up’s who previously couldn’t afford the larger infrastructures enjoyed by large enterprises could start to compete on a level-playing-field. Enter the world of ‘Agile’ Development. The key behind this is the dream of a Facebook like “unicorn” for investors and entrepreneurs/developers alike.

It was into this world where companies like Facebook embraced the principle of “Move fast and break things”, meaning that making mistakes were acceptable and seen as the essence of innovation.

While we should applaud the innovators and their approach, we can’t ignore the fact that these same organisations are moving into highly regulated banking systems and applications with little to no regard for our privacy or security.  It was never part of the design ‘requirements’. That is until they come across detailed information security questionnaires from investors and clients and they lose opportunities because of a lack of process and demonstrable security. Retro engineering this is far more expensive and slower than doing it from the get go.

Privacy & Security By Design

Over the years multiple Software Development Life Cycle (SDLC) models have been designed, but broadly the SDLC is made up of six phases, and has not changed since the 1960’s (when it was originally created).

The SDLC;

1) Requirement Gathering and Analysis.

2) Design.

3) Implementation or Coding.

4) Testing.

5) Deployment.

6) Maintenance.

Does this look familiar? Is this your approach? If so, where are the Privacy or Security aspects considered? Historically Penetration Testing or code security reviews would take place as late as stage four (Testing), way after there is any real chance of correcting any inherent risks or failures.

If this is your approach to SDLC then perhaps it’s time for a change.

The Future in Development

We’ve reached this phase in the blog where I am only just introducing the phrase ‘Internet of Things’ (IoT) and while I won’t venture too far down this rabbit hole, I wonder if we are sleep walking into a World of Insecure Things (WoIT)? If we don’t change our approach to Privacy and Security, I believe we are.

Our technological world has evolved rapidly around us and there is an awakening amongst society that is calling for organisations to think about our Privacy and Security, while still delivering the functionality we require. 

• Social media needs to be fun, engaging and secure
• Systems need to be Apps that areomni channel internet enabled adaptive, functional and secure.  Look at the emergence of Fintech and Banking apps that challenge the old “monolithic” mainframe based technology and mentality.

So what can we do? 

I believe we have two options;

Educate our developers so they understand the mindset of Cybercriminals and understand the vulnerabilities and weaknesses inherent in the applications and tools they use to code. Developers who understand the importance of Privacy and Security, and place these high on the list of ‘Requirements’ will be highly valuable in our WoIT of the future.

The second option is to bring in external experts who understand not only coding but also the weaknesses that exist in our systems. These experts should have a good grasp of not only the technical aspects of security, but also the legislative and regulated world in which they operate. 

Conclusion; Where do we start?

Our SDLC process is no longer appropriate. If it was, then we wouldn’t see so many breaches and incidents of software failures.  We need “SDLC 2.0”. It should incorporate models which have been around for a long time (e.g. OWASP CLASP or MS SDL).

Place Security and Privacy in your SDLC at several points throughout the lifecycle;

1) Requirement Gathering and Analysis

2) Security & Privacy Impact Assessment

3) Design

4) Security Code Review

5) Implementation or Coding

6) Testing (including Penetration Testing)

7) Deployment

8) Maintenance (ongoing Vulnerability Assessments)

If you’re worried this will slow down your ‘agile’ approach, or get in the way of your development processes, bring in experts who can help you design the approach. Having someone whose focus is on Privacy and Security can release your developers to do what they do best. But you do so in the knowledge that you’re not headed for a complete failure someway down the road.

‘Move fast and break things’ makes for a rousing speech when facing an excited room of developers. But it’s possibly not the best moto to have when faced with a court case or when facing angry customers and clients.