Schneier on Security

Clive Robinson • August 15, 2013 11:56 AM

Perhaps I should sound a note of caution for non technical managers, and other more technical managers who have not specialised in security.

Sometimes something that appears a very senible idea in a technical or engineering perspective is a very bad idea from the security perspective.

Two of the more memorable instances are CarrierIQ’s “test and support” software that did an “end run” around all the security built into a smart phone by dumping raw keypresses and other information directly onto the Internet. And RSA’s “customer support DB” which was accessable to the internet because it was not “air gapped” and contained the seeds and other information required to break the security on just about all of their two factor key fobs on which many of their customers security relied upon.

Now consider this, as far as an organisations customers are concerned their relationship is with that organisation, not any other entity the organisation has dealings with. If your organisation buys in technology from a third party entity it’s your reputation profits and continuance of your organisation that matters to you. Your customers won’t see it as some entity letting you down but you failing in your duties to them, likewise any court or judicial body such as a regulator (SEC etc) if the customers or authorities decide to take action. You might be able to take civil action against the entity but the odds are it won’t happen in any short time frame and it also won’t be successfull…

Clive Robinson • August 15, 2013 5:58 PM

@ Simon,

– the problem with your comment is, that it sounds like you know ahead of time which ideas are good. But you don’t. You are using information afterwards to make it sound like you would not have made the mistake.

I don’t know what you do for a living or how many years experiance you have, but hopefully you understand the notion of “Due Diligence” and how it effects a company when one of the legal proffession gets hold of it in court or worse a regulator that can place arbitary fines and or imprisonment on executive and non executive directors?

ICTsec has no real or worthwhile metrics to demonstrate that a company has taken reasonable steps to ensure the “marketable performance” of it’s products. Thus people fall back on “Best Practice” which from a defence position is a very bad place to be in. Effectivly all a lawyer has to do is find another company performing similar activities which has taken preventative steps that your company has not, and if they can show it has a bearing on any “unfit for market” parts of your system it’s in effect game over unless you have in some way prior to marketing the product limited your liability not just in general but specificaly with respect to the type of harms claimed.

If it can be shown that you actually added functionality that does an “end run” around security features that are in your product then a court or regulator is going to rip away any chance of a defence you might of had, because it’s moved from negligence to fairly easily demonstrable willfull behaviour.

Claiming ignorance of ability to check the security of a product prior to release is likewise not going to do you any favours.

The only reason we have not had a court case of any substance in the US is due to a quirk of the US legal system which alows large organisations to defend themselves by “out spending” a littigant and thus in effect striping them of their rights under law. Or where the littigant is another large organisation or a regulator an accomadation by way of an out of court settlement is made.

Thus an organisation of any worth should be duely dilligant and perform best practice testing prior to “placing on the market” any product they have designed, produced, manufactured or re-labled, even if they are not providing it to make direct comercial gain from the end users as in effect the “something offered, something gained” of contract law applies.

With regards your statment,

So, if I’m wrong, then go ahead and disclose all the weaknesses in all systems in use now. Go ahead. Don’t leave anything out. See how that works

You know or should know that that is an impossible “ask” the reason being quite simple for two reasons.

The first is,

There are known knowns, unknown knowns and unknown unknowns.

The second being a couple of mathmatical proofs from before the first working computer that indicates there are various limitations of logic and mathmatical questions that our current notion of a universal computer (Turing engine) cannot resolve. The consiquence of this is there will always be vectors via which such a computer can be attacked.

If you can be bothered to search back on this blog you will see that I have said both of these a number of times befor and have also made proposels for a “probabalistic security” system that whilst it can not stop attacks can detect them fairly rapidly alert human operators and halt.

But just to ensure you understand what known knowns, unknown knowns and unknown unknowns mean I will go through it.

First you have to accept that any one attack is infact a specific instance within a more general class of attacks. Thus an attack that exists is a “known” specific attack within a “known” class of attacks. A variation of an existing attack that has not yet been seen is an “unknown” specific attack within a “known” class of attack. Thus an entirely new type of attack using a new method would be an “unknown” specific attack in an “unknown” class of attack.

In normal anti-malware systems there are two approaches one is to look for a specific attack the other is to mitigate against a class of attack. Of the two class mitigation is a better but considerably more difficult aproach, as it provides protection against many zero day attacks which malware signiture style systems don’t as they need a known signiture for the malware to be detected.

Further if you search back through this blog you will see I have discussed a number of times an issue most software developers have difficulty accepting which is “Efficience -v- Security”. Optomising code fore efficience unless you realy know what you are doing is almost always guarenteed of opening up various side channels through which information will leak.

I have in the past highlighted some of the required stratagies for reducing your security surface and put simply it’s the same as it is for hardware design. You reduce the complexity in your code by segregation and interface control, further you remove all functional feedback and feedforward and adopt where possible a “single chain of execution” approach, which means no test stubs or harnesses in the product. Further you reduce the transparancy of the product by clocking the inputs and clocking the outputs as well as failing hard and long on any error.

Fully understanding the why of these rules and following then correctly will go a very long way in improving not just the security of a product but the reliability as well. With once you are experianced in the mind set fairly minimal increase in coding, but a consiquently greater time saving when going through the various test phases.

I’ve also in the past given a list of EmSec / TEMPEST rules for hardware design, however most also translate into software as well when you can visualise the analogs.

Further you will find comments and posts from other regular posters such as Nick P giving guidence on formal methods for producing secure code, available secure OS’s and importantly a list of past papers.

It is this last point you should consider, back in the 1960’s and 70’s most of the things you need to do to produce secure OSs and applications was not just known about but discussed in published papers from both the theoretical and practicle view point.

Saddly for most developers this trove of information is unknown to them for various reasons. And worse even if it were known it is unlikely that most organisations would alow the knowledge to be used, because managment and marketing have in the main not seen a need for security and thus regard moves in that direction to be a waste of resources.

From your closing comments of,

Why don’t you go fix something. The world is on fire and there are enormous problems that need fixing. Not more of this conceited crap.

You make a series of unwarented assumptions about me, without any knowledge of me which does not bode well of your thought processes. And is bordering on trollish behaviour.

For your information I used to be what some Americans call a “fireman” or more pragmaticaly a trouble shooter for hire. I used to go in and pull projects back on the rails when they had jumped the points. To be able to do this I needed a lot of skills oddly mostly technical not human. These skills came from many years working in many diverse fields of endevor within engineering. What has stopped me doing this is ill health that amongst other things makes flying medicaly inadvisable.

I do however continue to perform various usefull functions in ICT as well as some research so I am still “fixing something” on a regular basis.

As for the world being on fire, as I’ve indicated above the reason is not a lack of knowledge or tools that have put us in this position but the simple fact that security outside of a very small and quite select market is not seen as a “money earner”. The upshot of which is few if any designers of products and systems have any knowledge or experiance of security requirements, let alone how to go about building them into products and then testing.

In effect it’s become virtualy “lost knowledge” and it is this issue that has in effect put all the fuel where it can be easily lit.

As for “conciet” I’ll let others draw their own conclusions, but as I’ve repeatedly posted to this and other blogs about these issues long before our current problems it is going to be more than a bit difficult to make your assumptions stand in the face of contradictory evidence.

But at the very least go back and re-read what I wrote in my comment above, I think you will find on reflection I was advising caution and giving real world examples of why it should be excercised.