[additional reqs] (was Re: Comments/suggestions on draft)

[George Jones <gmj@pobox.com>]

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

> Here are some additional requirements I thought we might want to
> include. This is just food for thought at this point. We can debate on
> whether these should be requirements or not. While others have stated
> that your draft is route-centric, they may find my requirements to be
> NIDS and firewall-centric. But, that's what I have the most experience
> with:
>
> Architecture-related requirements:
>
> 1) Vendor appliances should be rack-mountable and not have unusually
> restrictive power or cooling requirements.
>
> 2) Device should be able to operate with a multiprocessor architecture
> with multi-threaded code
>
> 3) The product architecture should provide the flexibility to allow
> either centralized or distributed management and control of devices.

These are operational concerns, not security concerns.

> 4) Product components using public-key cryptography should securely
> store their private keys.

So give me a counter example.  I assume you mean on the device.

This releates to 2.2.2 (display of sanitized configs).

So here's a question.  How do we define "config" ?   Are
public/private keys part of the config ?  Should they
be displayed/retrieved if the operator has sufficient
authorization ?

> 5) Product components straddling a firewall must communicate using
> protocols that can be securely proxied through the firewall.

I'm thinking 3.1.1 (secure management channels) covers this
with sufficient generality.   Proxying is a mechanism/implementaiton.

>
> 6) Where possible, the system architecture should provide the option for
> component redundancy to prevent single points of failure.
>
> 7) The device should provide a watchdog capability to automatically
> re-start or reboot a “stuck” component.

These are both aimed at improving availability.  Unless you care to
argue that the availility that these provide is critial to security,
I'm going to say these are more operational than security.

>
> 8) The product should provide the ability to store the raw data stream
> (e.g., network traffic, system logs, etc.) portion triggering an alarm
> for later forensic analysis.

This is kind of where 3.3.2 (Traffic Monitoring) was going.
This is is a large area.    I'm wondering whether this (and
3.3.3 Sampling) are too large for the scope of this document.

There is other active work in the area:

  http://www.ietf.org/internet-drafts/draft-baker-slem-architecture-01.txt
  http://www.ietf.org/internet-drafts/draft-baker-slem-mib-00.txt

  http://www.ietf.org/html.charters/psamp-charter.html

  (am I missing other efforts ?)

Do monitoring and sampling belong in this doc ?

>
> 9) The vendor should implement mechanisms to support device
> load-balancing capabilities.

Operational.

>
> 10) Filters should be easy to apply. This means the administrator can
> specify IP address blocks, port ranges, etc in one filter rule.

Subjective.

>
> 11) Device should support user account lockout upon x unsuccessful login
> attempts.

Reasonable.  This is an area that needs some work.  Some reqs that
need to be stated explicltly:

  - Disconnect after N bad atempts
  - N settable
  - Disable  after M bad atempts
  - M settable
  - Delay of at least X secs after bad attempt
  - X setttable

  - Certian account(s) (ROOT/ADMIN) can not be locked out

Related things that need to be added:

  - ability to do emergency "root" password recovery with physical
    access

Related descions to be made:

  - capabilities required for local auth vs. Remote (ACS/AAA/Auth
    server) auth (per Chris Lonvick, Ericb)

  - Which strength checks (comutational, strength/static,
    strength/dyammic per Neal Ziring) to do localy, remotely.

FWIW, the T1M1 doc addresses some, but all of these.

Volunteers to think about/draft these ?

> Installation and configuration-related:
>
> 1) System installation documentation should include steps to verify
> proper operation upon completion of installation.


Operational.

>
> System management-related:
>
> 1) The vendor should implement mechanisms for group device management
> that improve management scalability.

Operational (unless you want to argue that poor tools to manage large
installations will result in sloppy/incomplete changes making it
marginaly a security issue).

>
> 2) The device should provide a robust command line interface (CLI) as
> backup to the management interface.

This has come up before.   Think about it.  Why do you want a CLI ?
(not that I'm arguing with you).   Just think about why you want it.
After you've thought about it, see 3.1.5.  Also see the
xmlconf/netconf work referenced, then tell me what you want added/changed.

> 3) The vendor should provide a straightforward mechanism for obtaining
> system software upgrades.

Interesting.  See 2.14.1.  Tell me if you think it needs
rewording/changing/addition.

> 4) The vendor should provide an automated mechanism for notifying
> customers when software upgrades and/or signature updates are
> available.

This is more of a process thing than a functional requirement,
but I can see the point.   Anyone else have thoughts on whether
non-functional things such as this should be included (Neal,
I beleive you referred to these as "assurance" requirements) ?

>
> 5) The system software upgrade process should be simple and involve a
> minimal amount of system down time.

"simple" and "minimal" are hard to quantify.

>
> 6) The device should contain the instrumentation and health monitoring
> to alert the administrator under the following scenarios:  1) Loss of
> communications, 2) System overload resulting in packet loss, 3) Little
> or no observed network traffic,4) software failures.

I think these are (should be) covered under normal network managemnt
practices/protocols/tools and are not unique to security.

>
> 7) The device should have the capability to synchronize with a Stratum-1
> NTP server.

2.10.11

>
> 8) The vendor must implement the capability to view device logs in
> real-time for administrative purposes (remotely and/or through console
> access)

This was weakly implied in the choice to require open standards
for logging (2.11.2) and in logging locally (2.11.7), but I think
making it explicit would be good.

Thing to be careful of is we are only writing requiremets for the
device and wire protocols, not for what happens on loghosts.

Things we want to preclue here are 1) buffering for "long" periods
before sending, 2) being locked into vendor-proprietary logging
systems that only give batch access to logs (you want to be able
to do a "tail -f" or load into a database in realtime to enable
intrustion detection,e tc.

If you'll take a stab at writing this up, I'll include it.

> 9) If vendor allows for granularity of logging facilities (e.g.,
> informational, critical, etc), the documentation must be provided
> specifying log message types that are included in each granularity
> category.

2.11.3 (catalog of messages) does not do it for you  ?

>
> Notification-related:
>
> 1) The device should be capable of providing remote notification of
> events via e-mail, page, fax, or SNMP traps.

What events ?

If 2.11.2 requires open standards.   Notification can be built on
top of that.

>
> Vendor support-related:
>
> 1) The product should be stable (i.e., relatively low number of bug-fix
> releases).

Subjective.   How would you word it ?

>
> 2) The vendor should be willing to provide source code escrow
>
> 3) The vendor should be able to provide long-term maintenance agreements
> with fixed pricing

These are busines issues and outside the scope.

>
>
> OK, that's it for today.

Whew.  That's a lot to chew on.   Thanks.

---George