[Security_sig] Re: DCL Capabilities section - highest level outline review

Ed Reed ereed at novell.com
Mon Sep 5 08:41:33 PDT 2005



>>> On Fri, Sep 2, 2005 at  8:01 pm, in message
<20050903000119.GD7762 at shell0.pdx.osdl.net>, Chris Wright
<chrisw at osdl.org>
wrote: 
> * Ed Reed (ereed at novell.com) wrote:

>> >> 	3.6 Availability and Continuity of Operations
>> > 
>> > Is that meant to dicuss DoS mitigation?
>> 
>> Among other things, but also that's where I'd put backup/restore,
load
>> balancing, m of n quorum clusters, RAID storage strategies, etc. 
This
>> is an area where Security and Availability features overlap.
>> 
>> But access to your data when you want it IS a security concern, and
>> there are many things to defend against (off- site backup, hot
standby,
>> automatic fail- over, process migration) that may be necessary if
your
>> building complex falls down (9/11) or all your power goes out
(eastern
>> half of the US power outage) or your data center blows away or is
>> flooded (pick your hurricane).
> 
> Ah, I see your intention.  We'll need to be careful, as it's a large
> topic.

Agreed - I stuck it in here just to stimulate the conversation.  High
Availability, which is what usually encompasses clustering and load
balancing, and Disaster Recovery, which usually encompasses backup and
restoration, as well as off-site fail-over, really do need to be
considered in the overall security context.  If for not other reason,
their security consequences need to be considered.


> 
>> >>  	3.7 Cryptography
>> >>  	3.8 Trusted Services
>> > 
>> > To scope the "trusted base"?
>> 
>> That wasn't my original intent.  Rather, the use of secure DNS, for
>> instance, when possible instead of plain DNS, or the use of xntp
with
>> authenticated time services instead of gambling you're not being
>> spoofed, etc.
>> 
>> Basically, extending the "trusted base" out to the critical network
>> infrastructure services on which your system relies to deliver
adequate
>> audit (for non- repudiation:  does your time base go backwards?),
and
>> authentication (are you talking to that partner's CA when you ask
for
>> the CRL for their certificate, or someone else?).
> 
> Do you consider the trusted base plus these trusted services to be
the
> scope of a TOE then?
> 

Of a networked TOE, yes.  Along the lines of the TCSEC Trusted Network
Interpretation.

Keep in mind that if you've got a network interface on your system,
you're networked and you need to be looking at security considerations
of that networked environment.

And if you're relying on networked services, for DNS, Time, DHCP,
NFS/SAMBA/CIFS/NCP, firewalls, SQUID, etc. - then those are all part of
your TOE, whether as part of your evaluated system or as part of your
trusted infrastructure.  That's really the point.

And, at the base level, developers and system administrators should
develop a bias towards using services (Time, DNS) that have
authentication and integrity, at least, properties in line with their
dependencies upon them.

For instance - don't sign up for non-repudiation deliverables if you
don't have a reliable, trustworthy time service.



>> >> 	3.9 Documentation
>> >>  	3.10 Installation & Delivery
>> > 
>> > These last two are not likely to generate technical capability
gaps,
>> > rather distro issues.  They're important, but lower priority IMO.
>> 
>> Well, only if you don't actually care if you've configured your
system
>> correctly, or that your running the right software or patches, or
that
>> you actually know what the design (never mind the implementation) of
the
>> packages you're running is.
> 
> That's esp. useful for certification effort.  But then the CAPP and
LSPP
> efforts are required to generate that design documentation (so
perhaps
> other than noting its usefulness and requirement for certification
> it's not a large section).  Certainly my focus is code centric, so
I'm
> thinking priorities start with functionality gaps.
> 

The documentation OUGHT to start with the developers.  Right.

Note that IBM published the High Level design documents for the SLES
CAPP/EAL3 evaluation under the GPL, and that's helped make it easier for
HP and SGI to follow in their trail.

Those docs should be captured and maintained by the community, in my
opinion.


>> Basically, these are requirements for any certification process
that
>> hopes to address confidence that the customers knows what they're
>> running.  I'd rather drive the docs requirement all the way back to
each
>> package, but know I have precious little hope of ever seeing that
come
>> to pass, except for the largest community projects.
> 
> One idea that's been tossed around is creating a repositorty for
those
> docs.  It's certainly one of the more (most?) expensive parts of
> certification, and large portions of it should be generic (not
terribly
> TOE specific).




More information about the security_sig mailing list