Crispin wrote: > That is not true. The Common Criteria evaluates the security of systems > largely in terms of how they are built, and additionally with respect to > what features they provide. For instance, it is a CC requirement that > all source code be under revision control. This requirement in itself > effectively makes it near impossible to certify a full Linux > distribution, because the code base for the hundreds of packages are > maintained independently. Too much info here, but: with Common Criteria, there's a set of security features and a set of assurance (correctness, if you will) features. You can use pre-canned sets, or you can pick & choose your own. Both are valid approaches according to CC (not commenting on whether that's a good thing or a bad thing... just a fact). Most of the predefined EAL assurance levels (all except EAL1 and maybe EAL2, I don't recall) require revision control. But there's nothing that stops you from defining your own assurance level, and call it CRISP37, which doesn't require revision control. Whether a buyer thinks that's good enough is a different question, but it's definitely possible, and you can definitely get it evaluated. Even at moderate EAL levels, there's nothing that says all of the packages have to be treated under the same revision control system. So the fact that Linux is maintained as a bunch of independent packages does NOT prevent it from meeting the EAL levels, providing you can describe each of the independent revision control systems. > >The Orange Book probably came closest, but seemed largely > unworkable, judging by its breadth of application: I believe only > one system was ever certified A1, > > > This is also not true. According to the NSA Evaluated Products List > <http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html>, two "network > components" have been evaluated A1, while *zero* operating systems and > applications have made A1. And if you check the historical EPL at http://www.radium.ncsc.mil/tpep/epl/historical.html, it lists the following products as having received A1 ratings: Boeing MLS LAN Secure Network Server System Boeing MLS LAN Network Component MDIA, Version 2 Gemini Trusted Network Processor Honeywell/Wang SCOMP Version STOP Release 2.1 [The difference between the two Boeing systems is a matter of some interesting politics at NSA. Also, later versions of the SCOMP were renamed XTS, and received B3 ratings.] So there have been both OSes and network components (the definition of which is a separate discussion). As Crispin notes, there haven't been any applications. > > and the most commonly applied level, C2, is so ridiculously > trivial that it was even awarded to Windows (albeit NT, not 95). > > > Yeah; C2 pretty much requires that you show up for the meeting, and > bring a check :-) As someone who's been through a C2 (as a vendor), I assure you this is NOT the case. C2 ratings were very time consuming and expensive (typically cost a vendor $10M and 3-5 years to develop the necessary documentation, make the miscellaneous changes required, and to work with the government folks). While C2 isn't particularly strong, a conscientious vendor will find and fix many security problems in the process. Having said that, C2 doesn't require any particularly knowledgeable penetration testing, and doesn't require any code review. But to say it's "just show up for the meeting and bring a check" is a gross understatement of the effort involved. If it were that simple, far more vendors would have received them. > > Personally, I have very little faith in proof of correctness > (a baase requirement for A1), as most proofs tended to be larger > than the code they were trying to prove. > > > I agree with that. > > All of which supports my point: early standardization is a disaster. The > Orange Book tried to standardize a discipline that is still not well > understood, resulting in a standard that is overly expensive and underly > effective, and therefore largely irrelevant to the real world. Absolutely agree. I'm not defending CC or Orange Book. --Jeremy
This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:57:59 PST