Schneier on Security

Clive Robinson • May 22, 2013 3:46 PM

There is one obvious point to make about this, where the authors say,

Defending the civil Internet in depth, and hardening it by re- architecting will allow its full social and economic value to be realized but will restrict the potential for espionage and surveillance by states.

Neither the “hardening” or “re-architecting” would be required if the likes of major commodity software companies had actually done their jobs properly rather than rush half baked overly featured software out the door on unsuspecting customers.

As I’ve noted a number of times before the only thing unregulated “free markets” are going to produce is a “race for the bottom” where first quality then reliability then profits are sacrificed to be perceived as “the first to market”.

Oddly perhaps making sure that a minimum amount is regulated actuall opens the market up to compeate on other asspects than “first to market” this gives not only consumer choice but also a degree of stability that alows specialisation in certain aspects that then become main stream.

An example of this is safety features in cars etc. When a certain minimum were required by regulation they had to be built in not bolted on. This caused design innovation which produced other benifits and a market for safety features that had previously not existed.

The hard part for legislators is working out what the minimum amount of regulation is to encorage the desired behaviour without stiffeling innovation.

Clive Robinson • May 23, 2013 7:58 AM

@ Winter, GRK,

Microsoft are one of many offenders and I’ve no particular wish to single anyone of them out when it comes to security.

Microsoft however with their relentless drive to make the world Microsoft by various actual and faux first to market techniques and later other less sulubrious techniques, did make themselves target number one with attackers simply because of their dominance at the time. We now see similar with Adobe and Oracle products, because they are on virtualy every user system and quite a few servers, and as the code base is generaly platform agnostic untill the build phase the same or very similar faults appear on all platforms.

I noted a long time ago on this blog certainly well before Google Chrome was even hinted at that the attackers game was moving from the OS layer to the App layer simply because many apps had become the equivalent of OS’s in their own right to get the performance but without the hardwon security that was going into OSs at the time. The app type I’d seen this start happening on back was web browsers and I discused it back in 95 at a University Masters course. At the time web browsers were in effect becoming the new “work environment” as developing for the desktop was considerably harder due to the issues with MS MFC amongst others. The easy attack vector being exploted at the time was the lack of state in web browsers, an issue that still haunts us today in many ways with what are in effect “session tickets” built around cookies etc.

One reason MS got baddly hit was their building IE into the desktop in the way they did and because of it they are still paying the penelty.

However MS had another issue where security problems were rife and still are today and in some ways are currently the major cause of our current attack vectors. The issue is the support of legacy code across many updates in the OS, apps, protocols and standards.

For instance I know for a fact there are still people out there using Self Signed PK Certs which were made on systems that had a broken random number generator (none of which was to do with MS code but is still used with their code). The people that generated the Certs have long since left the organisations for “bigger and better” and those who have replaced them have no idea of the origin of the certs but fear changing them for many customer facing reasons.

As for the various security methodologies for production code cutters on commodity platforms none of them are sufficient, they are slow to bring into place and require all code cutters in the organisation do so, and all the legacy code still in use to get re-milled. As Microsoft have admitted there system is most definatly not for every one and their productivity took a masive hit during the initial phases.

It is rumoured that Oracle are fed up to the back teeth with Java due to the bad publicity, but for some reason are unable or unwilling to get a grip on the problem and resolve it. I’ve no relationship with Oracle or the old Sun teams these days so cannot say, nor can I confirm or deny the comments of others that have or claim to have a relationship with them. What I can say is that if the rumours are true it’s not that surprising the problem has been seen over and over again when one organisation takes over another organisation. As somebody once observed “We knew there would be teething problems but we didn’t realise we had to do puberty and stroppy teenager issues as well!”.

Security is hard, even for those with many years experiance, they are a rare resource and have a golden value. Most managment would rather buy in than train not realising that all code cutters have to be security aware, so buying in is not working for them the way they thought it would, and the number of developers with the required skills still remains well below that required. Consiquently code is still…

Further few realise that most of the code independent protocols were ad hock and were not designed with current security requirments in mind. But they still expect revision 0.5 to still work with 3+.

Belive it or not many standards are just the same take C with it’s fairly infamous security issues from K+R days. Well many got slurped into ANSI C and subsiquently they are still there in many C++ compilers as well.

It’s a mess that is going to take one to two programmer generations to sort out, but legacy issues will still be with us due to embedded systems. As I’ve noted befor electricity and other service meters and implanted medical electronics can have expected life times well in excess of a third of a century. DES died the death in considerably less time but it still has to be supported due to embedded systems that cannot be upgraded. If the original standards had included upgradability as part of the approvals process then we would be in less of a hurt area than we currently are. Which is just one reason I say we need to raise the game by legislation that requires standards to be met, and the standards to be appropriatly future proofed in some way.