Posted by on Wednesday, December 16th, 2020

The burden of software security often falls solely on security teams, but to be successful, organizations need to make security a team effort.

Remember group projects in school? Teachers love them because they have less grading to do; in a class of 25 students, they might only need to look at 5 projects.

For team members, team projects can be difficult, usually when individual motivation levels don’t match up. On the other hand, team projects can be rewarding when the work is shared and takes advantage of each team member’s strengths.

Software security is a kind of team project—everyone in the organization has an impact on security and risk.

Hush, little baby

A chain is only as strong as its weakest link. The same can be said for security. It won’t do you any good to lock 10 doors of your building if you leave the 11th door open.

The story is the same for IT security. You can install all the firewalls and intrusion protection systems you like at the perimeter of your organizational network, but none of that is worth anything if your employees are not being careful about security.

• Somebody might install their own unsecured Wi-Fi access point
• Somebody might install remote desktop software with weak authentication or no authentication
• Somebody might prop open the back door of the building so they can slip out for a cigarette
• Somebody might click a bad link in an email or message and end up with malware running on their computer

Clearly, IT security is more than just buying equipment and installing it in your network. You have to see the whole picture, and then apply defensive layers as appropriate.

Applying defense in depth is much like the lullaby Hush, Little Baby:

Hush, little baby, don’t say a word, 
Mama’s gonna buy you a mockingbird. 
And if that mockingbird don’t sing, 
Mama’s gonna buy you a diamond ring. 
And if that diamond ring turns brass, 
Mama’s gonna buy you a looking glass. 
And if that looking glass gets broke, 
Mama’s gonna buy you a billy goat 

As protection against users clicking bad links, for example, you could apply multiple controls:

• Train your users so they will be less likely to click on sketchy links. And if that doesn’t work…
• Use antivirus software, which will prevent some bad things from being run. And if that doesn’t work…
• Segment your internal network so if some malware does get installed, it can’t immediately spread to all parts of your network. And if that doesn’t work…
• Examine your egress traffic or use some sort of data loss prevention solution so that if malware gets inside your network, you’ll have a chance of finding out if it attempts to contact attackers or exfiltrate data. And if that doesn’t work…
• Make sure you have an incident response plan so if bad things happen, you have a smooth and practiced plan for responding.

The problem is that time and money are finite, and evil is infinite. You can never be 100% secure. The challenge is applying the available resources to achieve the greatest possible reduction in risk.

I am somebody

IT security is about using software; application security is about creating it.

Just as with IT security, application security is everyone’s responsibility. Unfortunately, when everyone is responsible, sometimes no one is responsible—everyone thinks that somebody else took care of it. As Lily Tomlin puts it, “I said, ‘Somebody should do something about that.’ Then I realized, I am somebody.”

The security of an application is the culmination of decisions made at all the phases of development. Weaknesses can be introduced anywhere.

Just as with IT security, you can’t simply buy tools and apply them to the problem. It won’t do you any good to locate and eradicate code weaknesses if the design of your application has inherent weaknesses.

If you go the other way and do only threat modeling, you might eliminate some of your design weaknesses, but you might write horrible, buggy code when you implement that design. Let’s say you look at security in both the design and implementation phases of your application, and you find and fix both design and code weaknesses. That still won’t do you any good if you deploy the application on an inadequate container image.

And maybe you do everything right by incorporating security when designing, implementing, and deploying your application. Even so, if a new vulnerability comes up in one of the open source components you used in your application, you still have a big problem.

When we say that security needs to be part of every phase of software development, we really mean every phase, from design to maintenance.

The whole enchilada

No one considers building an aircraft without safety being integrated into the entire process, yet software is often created with a negligible focus on security. Partly this is due to how humans perceive risk: we can vividly imagine plunging to earth in an airplane, but we fail to appreciate the consequences of software security failures.

But software is the infrastructure that supports all other infrastructures. Every industry, every company, and every government depend on a complex and interconnected web of software. Organizations of all types must confront software security by seeing the big picture and taking steps to reduce risk. Organizations that create software must incorporate security so it becomes business as usual.

One day we will all look back, shake our heads, and laugh a little about how we could ever create software without integrating security. Let’s work together to get there, so that every time someone says “software development life cycle” it’s understood to be “secure software development life cycle,” and every time anyone says DevOps, we all know it really means DevSecOps.