[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
|
|
Subscribe / Log in / New account

ROCA: Return Of the Coppersmith Attack

ROCA: Return Of the Coppersmith Attack

Posted Nov 17, 2017 6:45 UTC (Fri) by marcH (subscriber, #57642)
Parent article: ROCA: Return Of the Coppersmith Attack

> thus favoring security by obscurity.

The question "is closed-source more or less secure than open-source?" is often debated. I think the answer is "it depends on many other things" and that this question alone is not very interesting when taken out of context.

There's on the other hand a well known "Defect Cost Increase" theory (and picture) that explains why and how the later defects are found and the more they cost. I think this theory demonstrates in a much better and simpler way why obscurity is terrible for security: because it *delays* the discovery of vulnerabilities - in this instance *after* millions of vulnerable products have been sold and used.


to post comments

ROCA: Return Of the Coppersmith Attack

Posted Nov 17, 2017 7:33 UTC (Fri) by marcH (subscriber, #57642) [Link]

By the way the universality of the "Defect Cost Increase" theory (DCI for short here) is really and sadly underrated.

DCI typically refers to the _time_ between the moment a bug is introduced and the moment it is discovered and root-caused. However it also applies to _spatial_ distances like the one between the source code location of the bug and the other, distant part of the code that pays the price and crashes. So concepts like isolation, modularity, and the "problem of too many layers of indirection" are DCI examples/applications.

Similar to source code, the distance can also be "organizational", think distant teams in a very large company. This is why open-source is more efficient: it removes all the various shades of red tape between the guy who creates the bug and the other who finds it.

Going back to _time_ between bug and discovery, Continuous Integration is a super obvious application of DCI. So are static and compile time checks. Test Driven Development is yet another one where an initially failing test is implemented so defects are "found" even *before* they would be introduced.

Of course we know that engineers get into software development to abstract themselves away from the boring *space and especially time* constraints of the real world (and from their evil project manager incarnations), so it's not so surprising after all that DCI is not their primary concern :-)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds