4 ms·

There is also this thing of legacy code... What if 3, 5, 10 years from now when you have moved on to your next super project, but someone has based system XYZ o

by calgoo 11y ago

There is also this thing of legacy code... What if 3, 5, 10 years from now when you have moved on to your next super project, but someone has based system XYZ on your code. If they need to write a driver or similar, I'm sure they would be a lot happier to have a documentation that clearly states a design etc then a document saying: "This was hidden so big bad guys cant look!".

nickpsecurity 11y ago
High assurance requirements going back to Orange Book's A1 class said the source code and evaluation evidence comes with the software. Further, customers were encouraged to re-run the tests & compilation, generate the system on-site, set it up according to secure configuration guide, and report any problems back to vendor. They become part of the evaluation process although real work was to be done by security professionals at evaluation lab and NSA's pentesters. Here's an example of one from one of father's of INFOSEC that handed NSA's ass to them in 2 years of pentesting: http://www.iwia.org/2005/Schell2005.PDF http://www.iwia.org/2005/Schell2005.PDF The original was based on custom hardware and firmware because Schell etc had good foresight. :) It was put on Intel because DOD and commercial sector wanted commodity products. So, probably issues at those layers that could breach security. Nonetheless, the kernel was what was designed with high assurance and will illustrate nicely what comes out of that. Note that this was the 1980's when it was designed. Still more secure, easier to review, and easier to extend than most modern software... So, I'd have to supply customers the source to meet your requirement. I could also show them how to protect it. However, thanks to design approach, a high assurance proprietary system is easier to work with than a low assurance FOSS system. It's because the process absolutely forces that design to be a simple, modular, layered, and correct as possible. I wrote up some links on how that's done here in context of subversion and hardware: https://news.ycombinator.com/item?id=10478742 https://news.ycombinator.com/item?id=10478742

by calgoo 11y ago

nickpsecurity 11y ago

High assurance requirements going back to Orange Book's A1 class said the source code and evaluation evidence comes with the software. Further, customers were encouraged to re-run the tests & compilation, generate the system on-site, set it up according to secure configuration guide, and report any problems back to vendor. They become part of the evaluation process although real work was to be done by security professionals at evaluation lab and NSA's pentesters. Here's an example of one from one of father's of INFOSEC that handed NSA's ass to them in 2 years of pentesting: http://www.iwia.org/2005/Schell2005.PDF http://www.iwia.org/2005/Schell2005.PDF The original was based on custom hardware and firmware because Schell etc had good foresight. :) It was put on Intel because DOD and commercial sector wanted commodity products. So, probably issues at those layers that could breach security. Nonetheless, the kernel was what was designed with high assurance and will illustrate nicely what comes out of that. Note that this was the 1980's when it was designed. Still more secure, easier to review, and easier to extend than most modern software... So, I'd have to supply customers the source to meet your requirement. I could also show them how to protect it. However, thanks to design approach, a high assurance proprietary system is easier to work with than a low assurance FOSS system. It's because the process absolutely forces that design to be a simple, modular, layered, and correct as possible. I wrote up some links on how that's done here in context of subversion and hardware: https://news.ycombinator.com/item?id=10478742 https://news.ycombinator.com/item?id=10478742