RE: Writing Secure code[update]

• Previous message: Timo Sirainen: "Re: Preventing ptrace()"
• In reply to: Crispin Cowan: "Re: Writing Secure code[update]"
• Next in thread: Pavel Kankovsky: "RE:Writing Secure code[update]"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Jeremy Epstein" <jepstein@webmethods.com>
To: "Crispin Cowan" <crispin@wirex.com>, <frostbackeng@lycos.com>
Date: Fri, 3 Jan 2003 10:29:27 -0500

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

• Next message: Kevin Spett: "Re: JDBC PreparedStatements, Java Data Objects/O-R mapping, and SQL Injection"
• Previous message: Timo Sirainen: "Re: Preventing ptrace()"
• In reply to: Crispin Cowan: "Re: Writing Secure code[update]"
• Next in thread: Pavel Kankovsky: "RE:Writing Secure code[update]"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]