Re: T1M1.5 Document (related ANSI doc)

[George Jones <gmj@pobox.com>]

OK.  I lied.   I did a quick review and submitted comments (attached).

I think I understand the problem space you're playing in.
It's a complementary subset of what we're trying to do.
Let's keep in touch.

---George
						George Jones.
						MITRE Corp.
						7515 Colshire Dr., WEST
						McLean, VA 22106
						(703) 488 9740
						gmjones@mitre.org

T1 Secretariat
1200 G St., NW, Suite 500
Washington, DC 20005
t1ballot@atis.org

Re: T1 LB 1117
Document Number: T1M1.5/2003-007R3



This is a non-member submission regarding T1 LB 1117,
document T1M1.5/2003-007R3.  Please consider these issues.

I am working on a related effort through the IETF.
See http://www.port111.com/opsec/ for more info.


General: This tries to be a one-size fits all set of requirements.
	 The diversity of network connected devices is increasing.
	 Different device types have different requirements.
	 It would be useful to have some mechanism for defining
	 "profiles", or collections of requirements that apply
	 to certain classes of devices (core, edge, hosts, toasters..)
	 with possibly a few examples in the document, and a mechanism	
	 for extending it.

General: It would be useful to have an an "examples" or
	 "sample implementation" section with each retirement.

P. 13, 3.8/P.28 M-35

       Simplify CRITICAL SECURITY ADMINISTRATION ACTIONS
       to something like "any action which changes the operational
       state, access controls, or other configuration parameters
       of the devices".  Add "Including, but not limited to...[current list]"
       if desired.

       You want the ability to log ALL items that change the
       config or operational parameters.

P. 23, P. 30
       M-7 "key recovery" and M-50 "no mechanism to bypass login
       AUTHENTICATION process" seem to be possibly in conflict.


p. 28, M-36:
	Logging - Missing requirements: detection of lost logs/packets,
		  reliable delivery (TCP, etc).

p. 28, M37
	Logging/time - Logging should timezone, accuracy of at least one 
        second, device must be able to synchronize time (NTP, etc).

p. 30, M-50: 
        No way to bypass login ... what about password recovery 
        with physical access ?  This is important operationally.

p. 30, M-51  
	- No plain-text passwords displayed - make it more general:

        "An NE/MS shall only display information appropriate to
	 the level of the authorized user"

	 e.g. User sees no config data
	      System Admin sees some config data
	      root users sees all data
	      nobody ever sees...passwords

	This would require a pass at identifying data classifications
	and assigning classification levels to roles. 


M-60:	The paragraph following the requirement "The user must not
	be able to "shell escape"... seems to be a requirement
	in it's own right, and maybe should be such.

	It also seems that referring to "shell escape" is a bit
	to system specific (UNIX) for a general requirement.


Question - Do these requirements allow for primary authentication to be done
	   via TACACS/RADIUS (MS ?) with a local fall-back resident
	   on the NE, i.e. so that authorized users can still log in
	   to fix things if the network path to the auth servers is down?