New subject: [Bug 782916] value of security measures; no metric, no scope description

18 Jan 2012


      Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: value of security measures; no metric, no scope description
https://bugzilla.redhat.com/show_bug.cgi?id=782916
Summary: value of security measures; no metric, no scope
                    description
           Product: Fedora Documentation
           Version: devel
          Platform: Unspecified
        OS/Version: All
            Status: NEW
          Severity: unspecified
          Priority: unspecified
         Component: security-guide
        AssignedTo: eric@christensenplace.us
        ReportedBy: budden@nps.navy.mil
         QAContact: docs-qa@lists.fedoraproject.org
                CC: pkennedy@redhat.com, eric@christensenplace.us,
                    security-guide-list@redhat.com, oglesbyzm@gmail.com
    Classification: Fedora
      Story Points: ---
              Type: ---
        Regression: ---
        Mount Type: ---
     Documentation: ---
Description of problem:
The juncture between computer security and network security is inadequate --
too many seams which leaves too many man-in-middle attack opportunities.
The most egregious omission in this (otherwise pretty good) document is
treatment of SCOPE.  This probably belongs in the vicinity of 1.3.
Analysis first.  Map each of the security solutions you have in the guide onto
the ISO Reference Model:
Layer 1/2 security measures (like WiFi security) protect frames.  The scope of
the security is limited to a single segment.  No security beyond the router and
no security within end systems.
Layer 3 security protected datagrams (VPNs do this, IPSec ....).  The scope is
an enclave tunneled through an internetwork.  The protection cannot extend
beyond the VPN boxes, so data is wholly unprotected within end systems (and LAN
if the VPN box is associated with the last router).
Layer 4/5 security includes SSL (aka TLS).  You have a how-to for securing an
http server (good) but no admonitions regarding scope -- the security extends
from the TCP socket in one end system to the TCP socket at the other end of the
connection -- again no security inside the OS comes from SSL.
All of the above security measures protect infrastructure.  But they do not
protect the data.
Layer 6/7 security measures protect the data.  Here the scope _can be_ truly
end to end.  S/MIME is a good example (so is ssh and XML sign/crypt) where the
data passes over the internet and through the OS in protected form.  Only in a
fairly small space is the data unprotected.  In Evolution, for example, only
the parts of the UA that deal with composing, reading, ... mail are places
where the authenticity and confidentiality of the data is possible.  Most of
the rest of the UA (including all the filing system deals with data that has
been protected exactly the way it's been sent over the network.  In the case of
Evolution (UAs differ in implementation) secured data is stored in the file
system exactly the way it was transmitted.
Recommendations:
 1) include a mapping similar to above so users have an idea what the scope of
this or that security measure is.  
 2) emphasize those security measures that apply to applications (layer 6/7) as
Fedora distribution evolves and matures.  (What got me here this morning is the
continuing frustration getting Evolution to properly play ball with DoD CAC
cards ... works, but doesn't 'just work').
Version-Release number of selected component (if applicable):
Security Guide 16.3 (doesn't have a date)
How reproducible:
The above analysis doesn't invent anything; it only organizes and sorts. 
Anyone can reproduce it.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 782916] New: value of security measures; no metric, no scope description