How to cyber security: Embedding security into every phase of the SDLC

On May 6, 1937, the Hindenburg airship burst into flames while docking, causing 35 deaths and bringing the airship era to a sudden close. In hindsight, it seems tragically obvious. Fill a giant bag with highly flammable hydrogen gas and trouble is bound to follow.

But hydrogen is also especially buoyant, which means airships filled with hydrogen could carry more passengers and more cargo than airships filled with other gases. Helium, which is not flammable, would only allow for about one-quarter the payload, and it’s more expensive and harder to obtain.

Someone, at some point, decided that the functionality offered by hydrogen was worth the risk. Maybe they didn’t fully understand the risks, maybe they underestimated the risks, or maybe they just closed their eyes and hoped for the best.

The challenge with building secure software

People who build software face similar choices about risk all the time. As a species, we build machines to do work for us, but frequently we neglect questions of safety and security in pursuit of functionality.

Software applications are nothing more than extremely complex machines. Software has enabled us to layer complexity on top of complexity to do wonderful things, but our ability to make sure things work right lags far behind our ability to make sure things cannot be exploited by bad people.

Part of the problem is the dizzying pace of innovation. We simply haven’t had time to get used to building one kind of software before we start building the next kind of software, and the next. Software technologies come and go like mayflies, and we’re just building, building, building as fast as we can.

What is becoming acutely clear is that security cannot be separate from software development. If you don’t think about security when you’re designing software, you will probably have design flaws that no amount of clever coding will be able to fix. If you don’t think about security when you’re testing software, you will leave vulnerabilities in your software that attackers can exploit. If you don’t think about security even after release, you won’t know about new vulnerabilities found in open source components that are part of your software.

Security and the SDLC

Thinking about security through every phase of development is the basis of a secure software development life cycle (SDLC). But that’s only the beginning of the story. Software products developed using a secure SDLC can still be deployed and used in an insecure way.

For example, imagine you run a bank. You carefully research online banking software and find a vendor that uses a secure SDLC to create its product. But if you deploy that software into a cloud cluster with weak authentication or poorly configured access, attackers can compromise the software and its data. And if you deploy the software but assign every user the same password, attackers can access anyone’s account. And if you deploy the software but forget to use HTTPS, attackers can see passwords and data as they go over the network.

It’s never safe to assume that security is the responsibility of your vendor. Obviously, you must find vendors that are using a secure SDLC to minimize risk, but the deployment and operation of software are equally important. Even when you don’t create your own software, security must be deeply embedded in how you acquire and operate software.

Part of what is so exciting about software is that it is so easy. Anyone with a computer and the necessary gray cells can write software. A team of four developers working in a garage can create an application that upends an industry.