RE: Writing Secure code[update]

From: Jeremy Epstein (jepsteinat_private)
Date: Fri Jan 03 2003 - 07:29:27 PST

  • Next message: Kevin Spett: "Re: JDBC PreparedStatements, Java Data Objects/O-R mapping, and SQL Injection"

    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