Schneier on Security

Clive Robinson • January 17, 2009 2:14 AM

@ Anon,

“… give us something constructive. Tell us some things organizations should know above the level of specific bugs. What should developers know? Where do I start learning?”

Where do I start…

1) You work in a busines where the man that cuts your cheque at the end of the month does not speak technical :- learn to speak his “business speak” and put your technical issues in that language then he will listen and not go off to sleep when you walk through his door.

Also it will stand you in good stead when you get promoted or go out on your own so it’s a good investment of your time.

2) I disagree with the point where he says bugs : design 50:50, He has left out use of poor tools used badly (GIGO) and a few others.

However sticking to his two I would say that 90% are due to poor design in several areas. Primarily “input” “exceptions” “APIs” “documentation”.

Most programers by habit push all input validation as far to the “left” as they can primarily because the do not know how to deal with exceptions properly or at all…
And most code cutters realy don’t know how to break their code up and design clean well structured interfaces.

I should not need to see any of your source code to write other parts of the program, either as part of the “initial code cut”, or for “bug maintanence” or “upgrading”.

If your APIs are designed properly and documented properly and your code handles exceptions properly then,

I should be able to write my code and test it to the API and drop it in and have it work.

3) Testing :- Most code shops do not test properly or at a level where they have an real degree of certainty on “functionality” let alone “security”. This is due in part to my above two points…

4) Metrics :- here I very much agree with the article writer if your only metric is number of bugs squashed then you realy are in trouble.

The problem is that most metrics you see are for audit and are about as usefull as a choclate teapot to architects analysts and programers.

This is a real problem as the industry as a whole does not have consensis on what should be measured or how and most support tools metrics are for accounting and audit (at best).

5) Tools :- get them, learn how to use them properly, use them, and pester the company that supplied them to get features you need (unless you tell them then their marketing dept are just going to guess).

You would not belive the number of times I have seen very expensive tools become “shelfware” simply because nobody has the time…

6) Programing Languages :- the author is correct they suck, but not just from the security aspect (though the ANSI C spec has a lot to be blaimed for on that score).

Most studies show that the strongest indicator of bugs in a program are related to the number of lines of code written by a programer irespective of the language used… So pick a language that is appropriately high level to the job you are doing that way you will have less lines of code written by programers, and they will get more done in the same period of time with less bugs.

Also being able to work in more than one programing language will help turn you from being a code cutter into a programer.

C++ et al suck because they try to be all things to all men and like the jack of all trades they fail to be a master of any. Worse they all have C in their past either directly or by methodology so have inherited some real bad traits.

7) Be an Engineer :- “software engineering” is a term I loath and despise.

Few software analysts, architects, designers, programers or code cutters use anything even remotly close to engineering principles or methodology.

Code Re-use and Patterns have been the mantra for some time which is about the same level as old style artisans making cart wheels and early steam engine builders. They make cart wheels the way they do due to evolution not science, in that they got to the design through things breaking and bolting a bit on untill forced by the laws of nature to come up with a new slightly different design. Those that worked went forward those that dident are lost in the mists of time.

However with software there are no laws of nature to force a new design. So every time something breaks a patch is bolted on and when that breakes that gets a patch and that in turn gets a patch…

Know the difference between a bolt and a bridge. A big problem with code reuse is code cutters design one bridge and cut it down to size for the river they are crossing or make it bigger. The next river the same, the bridge they use only ever gets bigger and the cutting more obvious. They do this Instead of making bolts etc and building the right bridge for the river they are crossing.

8) Learn by others :- this is a real problem. Everybody learns by experiance and knowledge. A clasic example was the Windows MFC, it was overly complex badly designed and documented, using it was a pig of a job until you learnt the “secrets”.
However programers treated it as a “rite of passage” in that they figured they had had to do the tasks of Hercules to get where they where and the hard won knowledge gave them a “competative edge” so they where not going to pass it on to others…

“Competative edge” “secret knowledge” call it what you want is self defeating it condems you and everybody else to the same Tasks of Hercules but without his abilities. Think how many times you have felt “If only I knew…” well the chances are somebody else has been in exactly the same position or one very close.

Know the difference between “war stories”, “parables” and “history files”. War stories have heros and villains but only one purpose to make the person telling them look the hero. Parables make general points and are supposed to make you learn but are generaly so vague to be of little practical use. History files however if written correctly contain the hows the whys and facts both good and bad of the problem and are of very practical use both as an aid to memory but as a body of knowledge for others.
Therefor if you have found a way of doing something don’t keep it to yourself document it warts and all and let others learn from your hard won knowledge, and ask them to let you know if they found it usefull or have improved on it etc. Most won’t but some will so you and they have benifited.

9) Education is a life long process :- take the time to read books journals and blogs and as I was once told, as a programer “learn a new language every year”.

But importantly realy learn the fundementals they are transferable skills knowing the secret tricks of a tool or language is only useful for a short time, and confuses others (think the obsficated C contest 😉

Also there is no “one way” to do a particular job the broader your range of skills the more insight you will have as to how best to do the job.

I was once told,

If all you know is how to blow glass skillfully you are not going to be a lot of use in the carpenters shop. Likewise knowing how to use a hammer and chisel is not going to help you to much in the glass shop. However it will get you started in the masons shop. Knowing how to carve both wood and stone gives you more insight and oportunities.

And if somebody needs a bridge building the knowledge and ability to use both wood and stone will set you well above jobing carpenters and masons and with a little knowledge of engineering fundimentals you can be a bridge architect and designer.

There are a whole load of other points I could make but hopefully the above will help.

Clive Robinson • January 18, 2009 11:09 PM

@ ed,

“You’re all wrong.”

Err no, my point 1 I posted above (Jan 17 @2:14AM) covers your two points and several others that arguably are more important.

Superficialy your two points appear to be the main process drivers for software development. And in many cases yes they are the main drivers.

However as a number of organisations are finding out the down stream costs of poor design are hurting badly.

In physical product manufacturing poor design gives high “return rates” which due to asymetric costs (transportatio/rework) have a disproportiant effect on profit.
The soloution for manufacturing industry was to correctly implement Quality Assurance (QA) systems.

Due to the fact that software companies have effectivly externalised the asymetric costs onto their customers the main cost they see is the “redesign”.

However the cost of redesign in physical products is usually quite low compared to that of software due to complexity issues.

And it is the complexity issues that are causing the down stream costs to hurt in some organisations.

In new or small software products complexity issues are often managable so the redesign cost is often marginal to the overal development costs.

However in older or larger software products complexity issues rise dramaticaly (n^x where x is >3) as do the attendant redesign costs and these can in some cases be such that it would be less costly to start from scratch.

Security type issues general fall well and truly into the high order complexity cost bracket. Partly due to “new class” issues but also due to the relative position in the software stack (app level less complex than OS level etc the worst being standards and fundemental building blocks like MD5).

However due to other technical (legacy etc) and business (customer baase, market credability etc) issues starting from scratch is offten not possible.

Therefor the efficiency advantages of QA seen by physical product manufactures are applied to the software build process.

It can easily be shown that the only way to manage quality issues is to build in quality across the whole process and that security is directly equivalent to this.

However outside of product design quality has been a bit of a hard sell to business managers simply because there are no easy metrics that can be used for ROI etc, which is the same for security.

However some non design/manufacturing business organisations had quality forced on them by their customers or regulatory processess.

What was found was that those organisations that took quality to heart saw improvments in efficiency, and those that paid only lip service saw decreases in efficiency.

Most business managers in medium or large organisations now regard quality as part of the business process effectivly as a given.

Security issues are from the business case almost identical to quality. Knowing this and knowing how to make the business case will make any security practitioners job considerably easier.

Importantly from QA is the recognition that a failure is part and parcel of the process and is dealt with by the mitigation asspects of the process.

Taking this view helps a security practitioner realise which metrics they should be using and why. But first they have to be business savy which means learning the walk and talking the talk.