[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: -00 draft next week
> From nziring@thecouch.ncsc.mil Fri May 9 07:19:57 2003
> Subject: Re: -00 draft next week
> From: Neal Ziring <nziring@thecouch.ncsc.mil>
> To: gmj@pobox.com
> Date: Wed, 07 May 2003 17:21:45 -0400
>
> George,
>
> Here are my initial batch of comments on the draft.
>
> I don't
> know what the right balance should be here between
> listing requirements that devices can meet today versus
> things we'd all like them to meet in the future.
This is one of the major tensions in the document.
Part of it wants to be a Best Current Practices (BCP) document.
Part of it wants require sensible security features that are
slightly beyond current practice (see netconf, reliable syslog, etc).
A few parts (stealthing) are "out there".
I've tried several times to resolve the tension, most recently by
splitting into BCP (current section 2), "Non-Standard Requirements"
(current section 3) and Advanced Requirements (current section 4). We
may wind up splitting into seperate documents for each class.
The document started life as a list of *customer* requirements for security
features and that's basicly what it still is.
>
>
> [ Part 2: "Attached Text" ]
>
> Comments on
> "Network Security Requirements for Devices
> Implementing Internet Protocol"
>
> draft downloaded on 6 May 03
>
> Date: 7 May 03
> By: Neal Ziring, NSA C4
>
>
> General Comments
> ================
>
> 0. It should be a primary objective, when writing these,
> requirements, to make them testable. An enterprise
> wishing to select a device for purchase should be able
> to take this document, a candidate device, and some
> network testing gear and actually validate compliance
> or non-compliance with each requirement. Most of the
> requirements are written to support this, but some are
> currently too vague or broad to permit testing.
This has been pointed out by others (a large router vendor).
Much work has been done to simplify the requirements and
break down compound requirements. More needs to be done.
I'm recruiting editors for different sections to help with
this. The goal is to have this completely addressed in -01.
>
> 1. Some of the requirements are too broad, and would be
> more cleanly expressed as two or three separate
> requirements. In general, requirements should be
> split under the following conditions:
> a. some parts are functional and some assurance
> or b. some parts are commonly implemented today and
> other parts are not available anywhere
See comments on previous section.
> or c. some parts are applicable only to core devices
> and other parts only to edge devices
This is what profiles are for. Merike Kaeo has agreed to
edit the profiles section.
>
> 2. Right now, the document distinguishes between the
> management plane and the data plane somewhat explicitly,
> but does not define them sufficiently well. Also, the
> intra-network control plane is lumped in with the
> extra-network management. At the least, some material
> should be added to section 1.7 defining management and
> data planes, and possibly control plane as well.
> (Perhaps the FORCES group has definitions you could
> adopt?)
It's on the todo list for -01 to revisit this. I'm also told that the
ANSI/T1 group is sarting to address this, at least on the voice side.
We should coordinate.
>
> 3. In the Common Criteria, there is a strong and explicit
> distinction made between Security Functional Requirements
> and Security Assurance Requirements. In this document,
> roughly 90% of the items are functional, and that is okay,
> but I still think the assurance requirements should be
> separate rather than sprinkled among the functional ones.
>
> 4. I think you might learn some things from the draft
> NIAP/CC Protection Profile for Routers and Switches.
> Version 2.1 may be downloaded from here:
> http://www.iatf.net/protection_profiles/switches_routers.cfm
> Of course, there is a great deal of overlap, and many
> of the requirements you have listed are also listed in the
> draft profile, but with (in some cases) more general and
> already-vetted wording.
> Also, if nothing else, the draft profile gives a lot of
> security objective and threat background matter that you
> might want to reference. (note, however, that the profile
> is somewhat slanted toward VPN routers, so there will be
> a lot of stuff in there that won't apply to your list of
> requirements.)
Thanks for the reference/pointer. The relationship between this
document and the CC and the ANSI T1.276-200 document needs to
be thought through. For now, I'm going to release -00. We can
think these through for -01 or -02.
> 5. In several places in the document, you state requirements
> for support of standard protocols, and then continue to
> prohibit proprietary protocols. In my view, this is a
> recipe for rejection by the vendor community. If a vendor
> wants to distinguish their product by supporting some
> fancy proprietary/legacy protocols in addition to standard
> ones, I don't see why this document should care. (For
> example, Cisco IOS Intrusion Detection supports logging to
> both standard Syslog and proprietary NetRanger protocols.)
You're probably right. I softened the wording on 2.11.2 (non-proprietary
loggging). I'm sticking with non-proprietary requiremetns for
encryption altorithms and display of configs.
>
> 6. Within sections, the rules don't seem to be in any
> particular order. At the least, they should be
> ordered to minimize or eliminate forward dependencies.
A pass will be made for for this in -01
>
> 7. For the final document, it might be nice to have a
> mapping from your requirements into CC general requirements.
> (For example, "Ability to Disable Directed Broadcasts" might
> map to an instance of FDP_IFF.1)
> If such a mapping is desired, I can generate it.
See comment above. We will revisit.
>
>
> Specific Comments
> =================
>
> Section Comment
> --------- --------------------------------------------------------
> 1.3 Change "protocols" to "protocol specifications"
Changed.
>
> 2.1.1 This section seems to mix OOB management and remote
> management. Must all devices support remote OOB
> management? I think this requirement should be
> restated to be more simple: the device must support
> a management interface that is usable only for
> management and not for data.
Defered to -01. Will delgate to section editors for management and
stealthing ("stealthing" is going to get renamed and folded under managemnt
as part of a group of requirements to support OoB management)
>
> 2.1.1 fix "fesable"
Done.
>
> 2.1.2 Is cryptographic separation an allowable mechanism
> for satisfaction of this requirement?
No. The ability to crash the forwarding elements should not imply
the ability to crash the control and management elements simultaniously.
>
> 2.1.2 The last sentence of 'Requirement' is redundant to
> section 2.1.3. Perhaps remove the sentence?
Done.
>
> 2.1.4 This requirement is a good idea, but its current
> wording is weak. The 'Justification' part gives
> the real general requirement, that data forwarding
> between data plane and management plane should be
> prohibited. The 'Requirement' part gives one
> mechanism: exclusion from the forwarding table.
Changed.
New Req:
It MUST NOT be possible to forward data
between data plane and management plane.
New example:
One way of meeting this requirement would be to have completely
seperate IP stacks and forwarding tables for management and
non-management interfaces and to prohibit propagation of
routing information between the two forwarding tables.
>
> 2.2.2 I'm not comfortable with the word obscured. The
> Vignere cipher used in Cisco IOS is a form of
> obscuration, but not one that I'd call sanitizing.
> Suggest replacing "obscured" with "elided" or
> "replaced with innocuous data".
OK.
>
> 2.2.2 Replace "BGP passwords" with "routing protocol
> passwords"
OK. Redid/expanded/generalized the list
>
> 2.3.3 This is a purely assurance requirement (ie. it is
> not a security functional requirement)
>
> 2.3.4 This requirement contains elements that are
> functional and elements that are assurance. It
> should be split: bullet 1 is function, bullets
> 2, 3, and 4 are assurance.
OK. On the -01 todo list.
>
> 2.3.5 This requirement should be restricted to externally
> visible services. There may be internal services
> that are not feasible to disable (e.g. memory
> management, logging) but which don't really matter
> from the viewpoint of attack surface area. Also
> the second sentence of 'Justification' needs
> rewording, suggest "The ability to disable services
> for which there is no operational need will allow
> administrators to reduce the overall risk posed
> to the device."
This applies to 2.3.4-2.3.7.
Try this (requirement):
<t>Provide a means to display all services that are listening
for network traffic directed at the device from any external source.
The mechanism should also display the interfaces on which each service
is listening.
</t>
>
> 2.3.7 This requirement should be limited to addresses
> that are actually assigned to the device. (Esp.
> since there is no explicit requirement that all
> devices support arbitrary loopback interfaces.)
Added:
Source addresses MUST be limited to addresses that
are assigned to interfaces (including loopbacks) local to the device.
> 2.3.8 The sentiment behind the requirement is admirable,
> but I'm not sure the requirement is sound in its
> current wording. The current wording mixes the
> notion of robustness (ability to resist classes
> of abuse) with bug-free-ness (absence of known
> vulnerabilities). I'm not sure how to fix it,
> though. Perhaps narrow the requirement to only
> layer 3 and below? Also, how could you test this
> requirement.
You could test it by beating on it with nessus and known 'sploits.
Set it up in the lab. Apply simulated (or real, if you are brave) load
and fire away. See if it falls down.
You can't prove a negative (the absense of bugs), but you can
prove their presence (I did this, the box fell down).
I redid the examples and warnings:
Examples Take for example the SNMP vulnerabilities described in [10].
These vulnerabilities were discovered and and toolkit for
exploiting them was publicly released. What this requirement is
saying is that known vulnerabilities such as this should be fixed.
It is up to the customer/operator to verify to their satisfaction
that the system is "bug free" and free of known exploits. Some
possible methods of doing this include
* Taking the vendors word
* Testing for themselves
* Relying on 3rd party testing/certification
Warnings
It is acknowledged that the number of known vulnerabilities is
constantly expanding and that it is not possible to prove that any
system is completely bug and vulnerability free (with apologies to
any computer science researchers who may think otherwise). Any
test or "certification" of a device to show compliance with this
requirement will be an approximation at a point in time. The most
that can be shown is that a given list of exploits failed.
>
> 2.4.3 I don't think this requirement is testable in its
> current form. Eventually, if I rate-limit dozens
> of ports and protocols on a Gig-E interface,
> degradation of throughput on that interface will
> be unavoidable. Further, does the statement
> refer to 2.4.1 or both 2.4.1 and 2.4.2?
> I think this requirement would be better as a
> SHOULD criterion on requirement 2.4.1.
Ok. Moved as a "SHOULD" under 2.4.1
>
> 2.4.5 The second sentence of 'Requirement' is confusing
> and doesn't really add anything. The first
> sentence is sufficient: ".. any interface
> implementing IP".
OK. Removed.
>
> 2.6.3 Is this requirement too broad? Do I really
> need to filter on TCP sequence numbers or UDP
> checksums? Suggest narrowing this requirement
> to non-volatile header fields, where "volatile"
> fields are those that are expected to change
> with every packet.
We'll see. If you've got the header open, I don't see whre allowing
you to specify arbitrary portios (a la tcpdump filters) adds overhead.
Its just a Small Matter Of Programming (SMOP) :-)
And I can think of at least one use of filtering on TCP sequence
numbers. Assume that there is a new exploit. Assume it only runs on
"Windows 200x, the New Choice of the Next Generation" for which we
know the ISN. You might want to filter on, say "port 80 && flags ==
syn and SN == xxx". That way, you could maintain web services
for the portion of users who surf from Net/Free/OpenBSD with lynx.
Ok, maybe it's not such a univeral, compelling case...:-)
>
> 2.6.4 change "as site to it's" to "a site to its"
Done.
>
> 2.7.3 This filtering requirement is too broad as
> currently written. Suggest splitting it into
> three requirements: (1) source address filtering
> for all management and control protocols, and
> (2) update content filtering for routing
> protocols, and (3) functional filtering (r/w)
> for management protocols.
Put on the list for -01
>
> 2.9.1 In 'Justification', change "log hits" to
> "filter rule matches"
OK.
>
> 2.10.3 I'm not comfortable with this requirement as
> written, because some smaller devices cannot
> forward data at full line rate even without
> filtering. I think what this requirement should
> state is that application of filtering should
> no impose a throughput penalty w.r.t. unfiltered
> operation. (e.g. I may slap a Gig-E interface
> on a small VPN router, but that doesn't mean the
> VPN is going to have 1000Mb/s throughput.
> However, I don't want the throughput to drop
> just because I added a few filter rules.)
Reworded Req to
2.10.3 Ability To Filter Traffic Without Performance Degradation
Requirement The device MUST provide a means to filter packets without
performance degradation. The device MUST be able to filter on ALL
interfaces (up to the maximum number possible) simultaneously and
with multiple filters per interface (e.g. inbound and outbound).
>
> 2.10.4 This requirement seems unattainable when
> juxtaposed with 2.11.4. Remote logging
> unavoidably consumes some bandwidth. Maybe
> qualify this with "other than bandwidth
> consumed by remote logging traffic."
Reworded the requiremnt
2.10.4 Filter, Counters and Filter Log Performance Must Be Usable
Requirement Filtering, logging, and counting functionality MUST be
implemented such that they are usable, from a performance
standpoint, in situations where they are the logical solution.
And added the following to the example section
Some examples of things that would make the logging features
unusable might include situations where their use:
* crashes the device
* consumes excessive resources (CPU, memory, bandwidth)
* makes the device unmanageable
* causes the loss of data
And the follwing warning
Warnings
While there are some objective measures that indicate clearly that
a feature is unusable (it's use crashes the device), "usability"
is largely a subjective term. Lab tests may be constructed to
determine how well the device behaves under certain loads, but the
ultimate test of usability for filtering, counting and logging
will come under live, quite possibly heavy, loads.
>
> 2.10.5 I understand the sentiment behind this
> requirement, but I don't think it is needed.
> Why should I care how filters are implemented
> internally as long as 2.2.1 and 2.1.6 are
> met?
OK. You're right. Gone.
>
> 2.11.2 The second sentence of 'Requirement' is a good
> example of my general comment #5. I don't
> care if a device implements a proprietary or
> non-standard legacy protocol as long as it
> provides full functionality in a standard
> form also.
Changed the second sentance to:
"Custom/Proprietary log protocols MAY be implemented
provided the same information is made available via logging
facilities that conform to open standards."
>
> 2.11.4 Should the device be able to log to more than
> one remote logging server?
Added
It SHOULD be able to log to multiple servers.
>
> 2.11.6 I think that requiring independent configuration
> of confidentiality, authentication, integrity, and
> replay rejection is a bit too burdensome. If I
> have the ability to run logs over IPSec/ESP, then
> get all of those things, but I may not get the
> ability to adjust them independently.
I'm going to leave it for now. See who complains.
> 2.11.10 This requirement and 2.11.11 might be in
> conflict. 2.11.10 says 'SHOULD' for specification
> of timezone, but 2.11.11 says 'MUST' for including
> a timezone in a log message.
Try this rewording for 2.11.10.
Requirement The device MUST maintain accurate, high resolution system
time. All display of system time MUST include a timezone. The
default timezone SHOULD be UTC. The device SHOULD support a
mechanism to allow the operator to specify the timezone for local
system time.
Second sentance added (and this is a compund requiremnt that needs
to be split out).
>
> 2.12.14 This requirement is a good idea, but the current
^^
I think you mean 2.12.4
> wording seems unclear. Does the requirement
> impose the need to be able to disable classes of
> accounts, or individual accounts? How can the
> device disable individual RADIUS accounts? It
> can't.
I restricted this to local authentication (default accounts, local users, etc.)
There's nothing I can do of if you create a radius user "cisco", give
it a passord of "cisco" with level 15 access.
> 2.12.8 first sentence, change "use" to "transmission".
Done.
>
> 2.12.9 Grammar issues in 'Justification' part.
Eliminated double "that". See if s/that// fixes it.
>
> 2.12.14 Should changes in privilege level also be
> recorded?
Added. The list is not intended to be exhaustive.
>
> 2.13.2 Last sentence of 'Requirement', I think that
> ARP-related requirements should be split off
> into a separate item or two. For example,
> while this requirement talks about VLAN
> isolation, do we also want a requirement about
> not doing proxy-ARP?
The whole of 2.13 needs a simplification pass. Noted for -01.
>
> 2.13.3 I think this requirement is unattainable for
> ports in Trunk mode. Therefore, you might need
> a requirement that the device be able to restrict
> designated ports to non-trunk operation.
I'll accept contributions (new reqs written up).
>
> 2.14 Everything in this section will be an assurance
> requirement rather than a security functional
> requirement.
We need to think through the functional vs. assurance thing for -01.
>
> 3.1.4 I appreciate the sentiment here, but I think this
> requirement is not quite sufficient. Even
> more important than linear scaling is the
> ability to perform key updates without
> substantially disrupting service.
>
> 3.3.2 Maybe mention RMON ?
Give me text for both of these.
>
> 4.1.1 The term "public interface" has not been
> defined. Does it mean all interfaces other than
> management ones?
I think we've got some legacy wording floating round. The management
model that is assumed needs to be rethought and explicitly stated
and a pass made to bring wording brought in line. Note made for -01.
> A.1 Since "Support Secure Management Channels" (3.1.1)
> is a non-standard requirement, I don't think it
> should be part of the minimum profile.
Note made.
>
> A.2 I think that this Layer 3 Core profile needs
> more logging requirements.
All the profiles need to be redone. As I've been adding/removeing/changing
reqs here, I have not been updating the profiles. As noted, I have an
editor lined up for this section.
Thanks for the input. It was well done.
---George