Last week, I got a tremendous amount of information about C2 from various WinInfo readers and, originally, I had intended to publish most of it. But I just received an interesting post from Frank Mayer, of Science Applications Internal Corporation (SAIC), the company that Microsoft has contracted to get Windows NT 4.0 evaluated for the C2 rating. Frank is a a long-standing and well-respected member of the security community, which is one of the reasons SAIC was chosen to work with Microsoft on the NT 4.0 evaluation. I think I'll just present his own description of the status of Windows NT and C2, since he does sum it up quite nicely and probably understands the process better than most.
Here it is, only slightly edited for formatting.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
There appears to be much confusion with regard to Windows NT and the status of its C2 evaluation. I'll attempt to set the record straight with the facts. My background with this topic runs from early in the evaluation efforts in 1992, where as a department director at The Aerospace Corporation, a federally funded research corporation, I was a member of the government C2 evaluation team for the original Windows NT evaluation, to today, where my organization at SAIC is conducting the current C2 evaluation.
Windows NT 3.5 was awarded a C2 rating in July 1995. This was a stand-alone evaluation (i.e. no networking was evaluated). The C2 configuration did require some permissions within the file system and Registry to be changed from their out-of-the-box defaults (it is well known that the default permission settings in Windows NT are not conservative from a security perspective). Other configuration and Registry settings were also included as part of this evaluation, some optional (e.g., crash on audit full) some not (e.g., "allocated" floppy and CD drive to interactive user). This is not atypical for C2 evaluated configurations.
As the Windows NT 3.5 evaluation was closing, discussions and planning between Microsoft and the government for a networked Windows NT 3.51 (later 4.0) evaluation were taking place. A team leader was assigned and a team formed. At this point (early 1996), I left Aerospace for SAIC and so have no direct knowledge for the next 9 months or so. In late 1996, SAIC and Microsoft began discussions about SAIC helping Microsoft move forward with the C2 evaluation of Windows NT 4.0.
In the summer of 1997, SAIC and Microsoft signed an agreement whereby SAIC would help Microsoft re-start the C2 evaluation efforts for Windows NT 4.0. Originally, we were to help Microsoft work with a government evaluation team to facilitate the evaluation. In early 1998, we transitioned the effort into an SAIC-staffed evaluation team under a government program that is commercializing the product evaluation program.
Our evaluation team has been working closely with Microsoft all year. A major milestone for this evaluation, the first of two government technical review boards (TRBs), will occur 29-30 September 1998. This TRB is NOT the point at which a "pass or fail" decision is made; rather it is intended to "ensure that the evaluation team has performed sufficient analysis of the product design" (See the "IPAR/Test Technical Review Board Meeting" section at this Web page). So it is indeed true that Windows NT 4.0 has not completed a C2 evaluation for a network configuration. However, it is also true that significant effort is actively being directed towards that end, and the evaluation is well into the evaluation process. The targeted evaluation version (subject to changes) is Windows NT 4.0 with Service Pack 4 in a closed network configuration.
Finally, I'd like comment on C2. A "product" evaluation is a fairly in-depth (by today's standard) analysis of an operating system (or other type of technology) against a standard (e.g., C2). The C2 requirements are entirely contained on 3 pages of text. It takes a lot of interpretation and analysis to asses compliance of something as complex as an operating system with something as simple as 3 pages of technical requirements. In order to keep the evaluation process tractable, an "evaluated
configuration" is defined that scopes the evaluation effort. Rarely if ever would a C2 evaluated product be "rated" with all the functionality supported by that product or in its default configuration. This is OK and, I'll assert, even good. Because what a C2 product evaluation is intended to provide is assurance that, for the "evaluated configuration," a standard set of security features (e.g., access and security auditing) at a standard level of assurance (e.g., internal design analysis and security functional testing) is assessed by an independent third party at a level of detail more than product consumers could afford. A user/integrator would then take that product, understand it's "evaluated configuration," and use that as a starting point for building a secure system. Certainly everyone deviates from evaluated configurations. However, now they have the opportunity to start from an established and evaluated starting point.
Frank Mayer ([email protected])
Center for Information Security Technology
Science Applications Internal Corporatio
