Heyaz. Just so everyone is on the same page without
wandering thru that whole doc, I thought I'd summarize ICSA's
"criteria requirements" here. I may offer an interpretation
as well, so feel free to call me on something I flubbed.
Also, of course, feel free to identify what you
know/think to be done already in a current LEAF distro.
As you can very well imagine, it's very doable if not done
already.
-Scott
---------------
Essentially, there are six total pieces:
RS: Required Services
LO: Logging Requirements
AD: Administration
FT: Functional Testing
ST: Security Testing
DO: Documentation
Each of those sections has about 3 or 4 subsections,
some of them labeled "conditional". The go as follows:
RS.1.1: A list of services that the firewall must be able to
allow real world access to. IE, the firewall must
support active FTP, HTTP/S, SMTP and DNS servers
located behind the firewall. No mention of NAT. It's
allowable (but not required) that the firewall require
these services to be on a DMZ.
RS.1.2: A list of services the LAN machines must be able to
use without trouble. Same list as above plus TELNET.
It's allowable (but not required) that the firewall
require these services to be proxy'd (eg, SOCKS).
RS.1.3: All other traffic gets denied. No Napster I guess.
RS.2: All of this must be accomplished without having to
install anything proprietary on the clients or the
servers (with the exception of management software
for the firewall itself). IE, it's transparent for
anything that speaks vanilla TCP/IP.
LO.1: Once it's up and running such a policy as specified by
the RS section, the firewall must have the ability to
log the following events:
1. Successful inbound connections to a protected server
2. Successful outbound connections to a public server
3. All attempts, from either side, to access some
service not explicitly allowed
4. All attempts, from either side, to send traffic to
the firewall itself that's not associated with an
explicitly allowed service.
LO.2: For each event that is logged, the following must be
recorded:
1. A date and time. Accuracy of time is in LO.3.
2. Protocol (eg, PROTO=6, 17, etc)
3. Source IP Address (is this really useful? ;)
4. Dest IP Address.
5. Destination port for TCP/UDP or Message Type for
ICMP.
6. How the event was handled (eg, ACCEPT, DENY, REJECT).
LO.3: Timestamp must be date, hours, minutes seconds. No
mention of NTP here, but its strongly implied.
LO.4: Logs must be human readable (ie, straightforward ASCII)
LO.5: Conditional: If logging is stored remotely from the
firewall, the FQDN or real-world IP number of the
firewall itself must also be logged.
LO.6: Conditional: If multiple logs are recorded for a single
event, there must be some clear means with which to
correlate the multiple logs to the single event.
AD.1: The firewall must have administrative functions to
support:
1. Setting up the above specified policy.
2. Enable the logging as specified above.
3. Conditional: if remote-administration is allowed,
either from the public side or LAN based, the firewall
itself must have the ability to configure that remote
administration.
AD.2: The functions of AD.1 must be accessible thru, gasp,
an interface.
AD.3: To access the Administration Interface, authentication
must be done; a password check at a minimum.
AD.4: Conditional: If remote-administration is allowed, then
at least one of the following must be enforced:
1. If being admin'd from the private side, use of the
IP# of the administrative client shall not be the sole
means of authentication.
2. If being admin'd via the public-side, then the admin
session must either be encrypted and/or a "strong
authentication" mechanism must be used (eg, but not
limited to, a one-time password).
3. if not #1 or #2, the remote-admin is disabled.
FT.1: Once it's up and running, the certification process will
test to see that every service which should work does,
and everything that should not work does not.
ST.1 Once it's up and running, the certification process will
test to see if it can obtain illegal access to the
administrative *functions*. Note that it doesn't say
access to the functions via the intended admin interface.
So buffer overflows here seem fair game to me.
ST.2 Once it's up and running, the certification process will
unleash some scanners on the firewall to test for known
vulnerabilities. Expect "ISS Internet Scanner" and
"Netect HackerShield" at a minimum. Reality, test with
NMAP and Nessus.
ST.3 Once it's up and running, the certification process will
test to see that nothing except the specified allowable
traffic can traverse from the public-side to the LAN side.
ST.4 Once it's up and running, the certification process will
test to see that the firewall correctly handles some DoS
attacks. It must:
1. Survive the trivial ones (eg, SYN flood, Ping of Death).
2. Fail *closed* for the DoS attacks of no known defense.
DO.1 The firewall must be accompanied with some documentation,
either written or electronic, detailing how to install it.
DO.2 The firewall must be accompanied with some documentation,
either written or electronic, detailing how to administer
and maintain it.
Last Updated: 29 Dec 2000
<END>
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
