Re: Comments/suggestions on draft [current requirements]

[George Jones <gmj@pobox.com>]

On Tue, 17 Jun 2003, Wang,Nai-Pin K. wrote:

> Abstract -
> You list some examples for devices that implement IP, like cable modems,
> personal firewalls, hosts. I think the term "hosts" needs to be
> clarified. Many
> people will think of hosts as including desktop workstations. Desktops
> should
> not be held to the same standards as critical server-class machines, for
> example.
> Are we really just focusing on critical server-class machines here? If
> so, we should probably replace "hosts" with "critical core servers".

See subsequent (still ongoing) discussion on the list.

>
> Requirement 2.1.1, second paragraph in "Justification" -
> Replace "It applies in situations..." with "This requirement applies in
> situations..." The "it" can be ambiguous.

Changed.

>
> Requirement 2.1.3 -
> 1) In "Requirement", remove the extraneous "of" in the sentence.

Change.

> 2) Add to the justification "If the device is compromised, filters
> may be modified by the attacker.

True, but that's not the point.  The point is that "if the only
separation is via filtering, management and non management traffic
can be mixed."   I've added that to the justification for clarity.

>
> Requirement 2.1.4 -
> IMHO, the example given is not currently a best practice, which is what
> section 2 is focused on. Unless I misunderstood the example (in which
> case, it needs to be clarified), this requirement might fit better in
> section 3 as a "non-standard" requirement.

I think you're right.  But this applies to 2.1.2 to 2.1.4 as a group.
I'll move them all.

>
> Requirement 2.1.6 -
> This requirement specifies storing and retrieving system configs from a
> remote server. However, there is no requirement for implementing
> mechanisms to ensure integrity of the configuration files. I think there
> needs to be a requirement along the following lines: Requirement: Device
> MUST provide configuration file integrity ensuring mechanisms.
> Justification: An attacker may modify configuration files upon
> compromise of device. Examples: Integrity could be ensured through means
> of calculating checksums of the configuration files. Blah, blah, blah.
> Something like that.

There are three places to worry about the integrity of the config:
(1) on the device, (2) in transit, (3) and on the remote system.
3.1.1 addresses (2), (3) is out of scope, sounds like you're
asking for (1), some sort of weak form of tripwire on the devices.
I can see a checksum to detect memory corruption, but if you're
going to do it for security, then you have to ask the question,
where do you store the checksum to compare against, how do
you validate it (signing, PKI....)....it just seems like a
*lot* of work for small/improbable gain.    Given 3.1.1
you could implement some sort of automated off-line config
fetching/diffing and achieve the same result.  I'm willing to be
convinced...


>
> Requirement 2.2.2 -
> I agree with a lot of this requirement. However, there are some examples
> given (all IP addresses and blocks, system names, domain names, banners)
> that I wonder if we're overdoing this requirement. If I were wearing my
> auditor hat, I would need
> to know what your IP addresses are, along with your warning banners, for
> example. If I were a system administrator, what's the point of me
> looking at the configurations if I can't see information like IP
> addresses and system names? I can see obscuring information like
> passwords and shared secrets, though. Maybe I misunderstood the
> requirement, but it just seemed overly done in the examples listed.

I'm actually having second thoughts about this one.

In giving it further thought, it seems that the right thing to do
would be to set up authorization levels (a la IOS's levels),
authenticate users and assign them levels (again, a la IOS),
and then to have the commands that display/retrieve configs
only display information that the user is authorized to see.

This requires classification of all config data.

The question is, if a user is not authorized to see something
(for example, SNMP community string configs), is the correct
thing to display the community string XXXed out (revealing
that there is an SNMP configuration), or just not to display
the SNMP config at all ?

I'm wondering about justification for the requirement.  Thoughts ?

>
> Requirement 2.3.1 -
> Do we want to include ARP and RARP in the examples listing as well, or
> is that implied? I just thought these were major enough protocols to get
> mentioned.
>
> Requirement 2.3.2, 2.3.3 -
> Do these requirements include proprietery protocols? If so, how much
> information does the vendor have to supply? As for the "Warning" field
> in requirement 2.3.3...
> from my experience dealing with vendors, this is going to be interpreted
> by the vendors as having permission NOT to disclose information about
> the protocols. EVERY vendor will opt for the case-by-case appeal. I
> think we should either remove the warning statement, or remove the
> requirement entirely. I don't know who would be dealing with the
> case-by-case judgements, but I wouldn't want to be them.

Note that this is a SHOULD, not a MUST.  As a consumer/operator, I'm
going to ask for it because I want it, but I'm also acknowledging
the business reality.

I think having this in as a SHOULD is reasonable.  Counter opinions ?

>
> Requirement 2.3.4 -
> What about disclosing which services get disabled upon installation of
> the product?

I only care about services insofar as they listen for inbound network
connections.   I think the requirements sufficiently addresses this.

 In addition, some firewall applications automatically make
> modifications to the kernel. Should this be listed as well? Some devices
> use stripped down versions of popular OSes as a foundation. Should the
> vendor document how the OS was modified?

Per ericb's recent comment, I don't think we want to get into
OS-Specific settings/mods.   It's a can of worms.

Which of course raises the question why have 2.3.14 (identify origin
of OS) ? and 2.3.13 (identify origin IP stack).

I think having this gross level of info is useful/justifiable.
If I know, for instance, that Windows NT/XP/2k/ME/etc. has trouble
dealing with certain types of ICMP packets, and I know that the
device is running on Windows *, then I know that that is something
worth spending time testing.  There is nothing prohibiting the
vendor from listing kernel mods, IP stack mods, etc that address
known problems, but I think requiring it is getting too fine grained.

>
> Requirement 2.3.8 -
> We should remove the apology to computer scientists in the Warnings
> field. This document is supposed to unify people (I know, I'm naive),
> not insult and drive some away.

OK.

>
> Requirement 2.3.9 -
> This requirement seems academic. I don't really know how to explain why,
> but it just seems like something that's already understood, and doesn't
> seem to fit with the rest of the requirements, which seems more
> applied.

OK.  Removed.

>
> Requirement 2.3.14 -
> Should the vendor also specify any changes that may have been made to
> the OS?

See previous comments.

> I'm thinking specifically of the stripped down Solaris 8 version
> on the Cisco IDS (Netranger), which was missing enough critical
> libraries that source compilation was not working.

In some circles, it is considered "wrong" to have compilers, Perl,
general tools etc. on security devices.   Minimalism is good.
Extra tools can be used against you.


>
> Requirement 2.6.5  -
> Maybe I'm missing something, or are vendors really horrific enough to
> call a device
> "Layer 2" and not have it be able to filter based on MAC addresses? If
> vendors are not this horrific, then do we need this requirement? If they
> are this horrific, wow.

Low end hubs may not support *any* filtering.   Here's a case where
the requirements need to be appropriately grouped in profiles.
For office desktop and web hosting setups, you want this
requirement (L2 Mac filtering).  For small SOHO setups, IP enabled
system controllers, etc, maybe you don't.

[your suggested additional requirements to be handled in a subsequent
message]

Thanks,
---George