5 ms·
Fascinating that the the lede here is the certifications. While some entities put a great stock in so-and-so certification, I have generally not put any weight
by pnathan 10y ago
Fascinating that the the lede here is the certifications. While some entities put a great stock in so-and-so certification, I have generally not put any weight in certification x or y, as they are pretty manipulatable if you are interested in doing so.
- digi_owl 10y agoBecause certifications is cover your behind thing for management in case something blows up. It allows their lawyers to go "we are compliant with X, Y and Z so the fault is not with our product/service".
- Spooky23 10y agoMy understand the cynicism over certifications like this, but they have value. In the case of FIPS 140-2, you have the assurance that the crypto module, say OpenSSL, was verified to work consistent with the FIPS spec, and that it was built in a manner consistent with that test. Now I get that FIPS has its issues, but the vast number of organizations lack the knowledge, skill and time required to evaluate the correctness of crypto code.
- pnathan 10y agoYes, I'm fully aware that OpenSSL is an excellent piece of software, well certified... Then, are the updates to OpenSSL FIPS certified... sometimes certifications expire for updates to things. TBH, the certifications seem like they are mostly a con to push bad quality to ignorant people. I think if I was securing Ubuntu, I'd be analyzing it based on threat models for the organization, then derive the specified behavior based upon that; only then would the manuals for the software come out. Analyze based on the needs of the enterprise I am involved in... Maybe this is too much a hacker attitude, but I really don't see why you start with certs or even care. Better to have a trusted firm evaluate for your organization IMO.
- Spooky23 10y agoWe're all familiar with the quality piece of software OpenSSL is. Most people regard OpenSSH as very well written software. But guess what? Poor procedural controls at Debian meant that lots of systems generated weak keys. Certification of a known, verified build process helps with that kind of problem.
- nickpsecurity 10y agoRemember that those are the most broken of the certification criteria. They just say it has certain features with a structured development process. Jonathan Shapiro had a nice write-up after Windows got EAL4+: https://web.archive.org/web/20040214043848/http://eros.cs.jhu.edu/~shap/NT-EAL4.html https://web.archive.org/web/20040214043848/http://eros.cs.jh... Whereas, medium to high assurance evaluations were more meaningful as they had stronger assurance requirements. Precise ways of looking at system, careful implementation, every feature corresponding to a requirement, covert channel analysis, pentests, SCM, trusted distribution, and so on. Those say quite a bit about what level of trust one can put into software. That's how it was originally meant to be done. So, you can put a little more trust in the TOE. Whereas, for EAL4, there's no reason to believe it's secure at all given the criteria are designed for "casual or inadvertent attempts" to breach security. Internet and insider threats are slightly more hostile than that. ;)