Re: survey of isp security practices

[Gregory M Lebovitz <gregory-ietf@earthlink.net>]

see inline...

At 04:03 AM 11/9/2004 -0800, Merike Kaeo wrote:
> I  missed the cut-off for submitting a 00-draft for the survey of current 
> isp security practices document but would like to at least send out the 
> proposed outline so that people interested in contributing can comment to 
> the list.  Anything that is glaringly missing?
>
> - merike
>
>
> Table of Contents
>
>    1.  Introduction
>    2.  Problem Statement
>    3.  Device Access Security
>      3.1   Threat Description
>      3.2   Best Current Practice

physical access? does this need to be covered here, not to become a phy 
security definitive work, but perhaps to outline key requirements and 
tactics and to offer other references that are more definitive?

>        3.2.1   Logical access
>        3.2.2   Console Access
>        3.2.3   HTTP
>        3.2.4   SNMP
>    4.  Authentication / Authorization
>      4.1   Threat Description
>      4.2   Best Current Practice
>        4.2.1   Device Access

specifically for administrative/configuration/polling etc. authorization?


>        4.2.2   Routing

of the routing peer, as would be contained in protocols (this is RPsec, 
no?) Do we need to address this here, or just point to the RPsec work?

>        4.2.3   MAC Address

Huh? This would be specifically for link-local peers only right? Doesn't 
work for multi-hop peers or other such things like NBMA networks?

>    5.  Filtering
>      5.1   Threat Description
>      5.2   Best Current Practice
>        5.2.1   General Inbound Traffic Filters
>        5.2.2   General Outbound Traffic Filters
>        5.2.3   Device Access Filters
>        5.2.4   Route Filters
>        5.2.5   MAC Address Filters
>        5.2.6   DoS Mitigation Filtering
>        5.2.7   SinkHole / Blackhole
>        5.2.8   uRPF
>    6.  Logging (accounting)
>      6.1   Threat Description
>      6.2   Best Current Practice
>        6.2.1   What traffic is logged
>        6.2.2   What fields are logged

This is a WG effort (or two) in and of itself.

>        6.2.3   How long are logs kept
>        6.2.4   Local buffer vs syslog (for backup info)
>        6.2.5   Authentication from peer to peer of log files?
>        6.2.6   Integrity check of log files?
>        6.2.7   NTP source considerations
>    7.  Device Integrity
>      7.1   Threat Description
>      7.2   Best Current Practice
>        7.2.1   Device Image Upgrade
>        7.2.2   Device Configuration
>        7.2.3   Management/Logging Information
>    8.  Specific Protocol/Service Concerns
>      8.1   Threat Description
>      8.2   Best Current Practice
>        8.2.1   ICMP
>        8.2.2   Generally Unused Services
>    9.  Policy/Procedural Considerations
>      9.1   Threat Description
>      9.2   Best Current Practice
>        9.2.1   Equipment Software Update
>        9.2.2   Equipment Configuration Change

Overall thought: may want to address it in terms of what you are trying to 
protect rather than how you are trying to protect, eg:
        - general security around device access (for config) and 
management/monitoring access
                - authentication/authorization
                - privacy
                - Filtering
                - message integrity
                - Image integrity
                - configuration integrity, verification, rollback
        - Security around routing information exchange
                - authentication/authorization
                - privacy
                - filtering
                - integrity
                - DoS protection
        - Logging content
                - traffic
                - data fields
                - storage
        - etc....



+++++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
W - +01 (1) 408 543 8002