Re: Scope, Profiles

[ericb@digitaljunkyard.net]

 "gj" == George Jones <gmj@pobox.com> writes:

gj> On Wed, 18 Jun 2003 ericb@digitaljunkyard.net wrote:
>> "dh" == Dan Hollis <goemon@anime.net> writes:
>> 
dh> On Tue, 17 Jun 2003, Wang,Nai-Pin K. wrote:
>> >> Are we really just focusing on critical server-class machines here? If
>> >> so, we should probably replace "hosts" with "critical core servers".
>> 
dh> How about "any device whos primary function is to forward packets"?
>> 
>> I'd go one step further.  Perhaps "Any embedded network device"?  Or
>> "Anything with an IP address that is not a general purpose host"?

gj> DNS Servers ?  AAA/ACS/Authentication servers ?  Loghosts ?

Hmm....  This thing started out to help us with vendor beating at
UUNET.  Things that we wanted from vendors that we were completely
incapable of doing for ourselves.

I can take a general purpose host and secure it to match just about
any security policy.  Install SSH, run RADIUS or Kerberos, disable
useless services, etc.  Give me a Cisco without SSH, and there's
NOTHING I can do to make it run SSH.  It's not an open platform (nor
should it be).

gj> It's pretty clear (to me anyhow) that we want those "hosts" to be
gj> in scope.  You also mention in a following post that you want
gj> some of the features listed here on things such as managable
gj> power strips, system controllers, etc.

And I'm not sure this is true.  Hosts are a whole different ballgame
when compared to embedded devices (Juniper routers not withstanding).
This document is a kinda cookbook style "The vendor must supply this
knob.  The end user must tune it to this setting."

This document was intended to be both educational and a conduit
between vendors and end users, so they could understand and negotiate
useful security enhancements.  Host security is well and thoroughly
addressed elsewhere.  Stick to our original charter.

gj> This highlights the need for greater use of the "profiles" mechanism
gj> defined in the document to enumerate lists of requrements appropriate
gj> to certian classes of devices.   You want your power strips to
gj> be managable, you want them to meet basic IP stack requirements,
gj> you probably don't want them to implement fitering of MPLS traffic
gj> or provide extensive packet sampling or monitoring capabilities.
gj> The requirements are a a group of things on the shelf, the
gj> profile is the shopping list for a particular class of device.

Well, things that I want for my powerstrips apply to anything with an
IP.  So it's not really profiles, but more "if you supply this
capability (IP stack, MPLS, etc), you must implement these features."

So at the front, there are some capability => feature mappings, then
as you dig deeper you get to stuff like "if you use the device this
way, you should configure it this way".

gj> This means that routers, switches, DNS/LOG/AAA servers, managable
gj> UPSs systems, SOHO + CPE networking gear etc are in scope,
gj> but web servers, end user sytems, etc. are out of scope.

Again, I would exclude anything running a general purpose OS.
Different can of worms.

Perhaps a good dividing line is configuration/software loads.  A
router has a single config file and a single software image file.  A
Solaris box has neither.

ericb