Still Waiting to Meet a Developer Who Wants to Write Insecure Code

A somewhat common refrain that you hear from security thought leaders is that secure coding is too hard and we shouldn't even bother trying. I have never understood this stance. Of the the thousands of developers I have met, trained and worked with, I am still waiting to meet the first one who actually wants to write weak, insecure code.

Sure lots of systems are poorly designed, but just because we have always built our cities out of wood does this mean the entire Infosec industry should focus on obsessing about threats like Mrs. O'Leary's cow and building a great fire department? If the city has no resiliency to any threat of fire, is the problem to work the threat side or the resiliency side? I am not sure that rounding up all cows and confiscating matches is the answer. Fire departments are very important and its great to get response time down from 10 minutes to five minutes, but still should this be the main focus? 

At a certain point, you need to say that we have got most of what we can from wood and move to building cities out of steel and concrete. Yes this requires new tooling, support and training for the people doing the building work, but its far from impossible.

Anyone who did web development in the early 90s knows it wasn't that easy then. Its easy for developers now and what they build is far more feature rich *and* robust. The protocols are the same, but what's different is 10+ years of engineering, training, and better tooling. Security is not any harder than most of the things developers do every single day, its just that it has not been prioritized by the wider industry yet. To throw software security in the "too hard" pile at this early stage is defeatism and puts a false and unnecessary ceiling on what developers are capable of. I say - empower developers with security tools, knowledge, and space to create, you will be surprised with what problems they are able to solve.

Comments

[Alex]

G-

I'll bite. In terms of data and network security, can you talk about what makes a resilient enterprise and what how we might measure resiliency?

[Jon Passki]

(sarcasm)
We can figuratively move away from wood, but the steel and concrete buildings still burn because of what's in them, not because of their structure. Earthquakes and strong storm threats, though are mitigated.

This sounds like someone (client, maybe?) triggered your response. What brought on this topic? I have never encountered someone saying we shouldn't do security because it's too hard, explicitly. I've seen it not done because of budgeting priorities, mismanagement, etc., but not ever called out.

[Gunnar]

@Jon: latest mjr there have been many others tho
http://twitter.com/mcgoverntheory/status/2115270911

@Alex:as far as networks, last time i checked networks are supposed to a) dumb and b) untrustworthy. seems like expecting more than that is a bad assumption.

for data, how about encyrpted data v cleartext?

[Rob Lewis]

Gunnar,

Another approach using your example:

Why not develop technology that makes wood inert and fireproof? It might take a decade or more to rebuild the city, or perhaps only new construction would be steel and concrete. What about legacy structures?

However, it might only take a year, or months to spray on a fire retardent barrier.

[Adrian Lane]

Sorry Gunnar, but I think that is a dubious distinction. I will posit that most thieves do not want to steal, but as no one is willing to hand them what they want, they steal because it gets them what they want. It is the direct path to achieving their goals and the items they gain outweights the percieved risks associated with the theft.

I meet young developers who want to write insecure code on a periodic basis. As the primary goal(s) of writing new code are focused on project completion, impressing the boss, or to look like they are actually doing something, I claim there is no practical differentiation between that and intentionally writing insecure code. The results are less subtle, but the code is insecure. Pure desire to write insecure code may be lacking, but as writing secure code is orthogonal to the primary goals, secure code is accidental. Is expending just enough effort to get the code checked in and past the nightly build materially different?

-Adrian

[Brian]

In many respects, secure software is a software project management issue.

I wonder how many of these 'security thought leaders' have read Fred Brooks' "Mythical Man Month", or Tom DeMarco's "Why Does Software Cost So Much"?

The important themes concerning the construction of complex software systems haven't changed much over the years.