[Security_sig] Re: DCL Capabilities section - highest
level outline review
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>
> * 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,
>> balancing, m of n quorum clusters, RAID storage strategies, etc.
>> 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
>> automatic fail- over, process migration) that may be necessary if
>> building complex falls down (9/11) or all your power goes out
>> 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
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
>> 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
>> audit (for non- repudiation: does your time base go backwards?),
>> authentication (are you talking to that partner's CA when you ask
>> the CRL for their certificate, or someone else?).
> Do you consider the trusted base plus these trusted services to be
> scope of a TOE then?
Of a networked TOE, yes. Along the lines of the TCSEC Trusted Network
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
>> > rather distro issues. They're important, but lower priority IMO.
>> Well, only if you don't actually care if you've configured your
>> correctly, or that your running the right software or patches, or
>> you actually know what the design (never mind the implementation) of
>> packages you're running is.
> That's esp. useful for certification effort. But then the CAPP and
> efforts are required to generate that design documentation (so
> other than noting its usefulness and requirement for certification
> it's not a large section). Certainly my focus is code centric, so
> 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
>> Basically, these are requirements for any certification process
>> hopes to address confidence that the customers knows what they're
>> running. I'd rather drive the docs requirement all the way back to
>> package, but know I have precious little hope of ever seeing that
>> to pass, except for the largest community projects.
> One idea that's been tossed around is creating a repositorty for
> docs. It's certainly one of the more (most?) expensive parts of
> certification, and large portions of it should be generic (not
> TOE specific).
More information about the security_sig