[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: profile

I sent out a starting document for profile appendix to George this AM......should have included list...didn't....(lack of coffee?!?) but am doing so now. If anyone has further comments, let's start discussing here. This will get incorporated into George's doc. Thanks.

- merike


> Here's text version of what I have so far for profiles.....I just edited.

Good start. Comments inline.

> Appendix A. Requirement Profiles
>
> A.1 Minimum Requirements Profile
>
> The functionality listed here represents a bare minimum set of
> requirements which any networking infrastructure device should
> adhere to. This includes all core and edge devices that work
> at layers 2 and 3 which are part of an IP network (such as routers,
> switches, firewalls).

Good.

> Note that SOHO equipment (typically DSL
> modem/routers, cable modem/routers, etc) and wireless networking
> infrastructure equipment have their own set of requirements and are
> not expected to adhere to this particular set of minimal
> requirements.

See my proposed scope changes....basiclly back to "large network
infrastructure"...I think SOHO and wireless LAN gear can be
defined to be in scope (contrary to my recent changes)....we
just need a more precise definition of "large network infrastructre"
that includes them.

> The minimal requirements profile addresses functionality which will
> provide reasonable capabilities to manage the devices in the event of
> attacks, simplify troubleshooting, keep track of events which affect
> system integrity, help analyze causes of attacks, as well as provide
> administrators control over IP addresses and protocols to help mitigate
> the most common attacks and exploits.

Good. This or similar text might want to find it's way to the front
matter as well.

> Device Management
> Support OoB Interface (2.1.1)
> Support Remote Configuration Backup (2.1.6)
> Support Management over Slow Links (2.1.7)
> Support Secure Management Channels (3.1.1)
> Support Scripting of Management Functions (3.1.5)

There is currently some confusion about OoB vs. Secure (encrypted) mgt
channels....this is a holdover from the UUNET doc where we assumed
an OoB management network.

I think it's reasonable to allow either OoB mgt OR encrypted/secure
channels (per T1M1, etc)....I think the requiremnt should be
that AT LEAST ONE of them be supported.

>
> User Interface
> Support Human-Readable Configuration File (2.2.1)
>
> IP Stack
> Comply with Relevant IETF RFCs on all Protocols Implemented (2.3.1)
> Ability to Identify All Listening Services (2.3.4)
> Ability to Disable Any and All Services (2.3.5)
> Ability to Control Service Bindings for Listening Services (2.3.6)
> Ability to Control Service Source Address (2.3.7)
> Ability to Withstand Well-Known Attacks and Exploits (2.3.8)
>
> Event Logging
> Ability to Log All Events That Affect System Integrity (2.11.1)
>
> AAA
> Authenticate all User Access (2.12.1)
> Support Authentication of Individual Users (2.12.2)
> Support Simultaneous Connections (2.12.3)
> Ability to Disable All Local Accounts (2.12.4)
> Support Centralized Authentication (2.12.5)
> Support Local User Authentication (2.12.6)
> Support Configuration of Order of Authentication Methods (2.12.7)
> Ability to Authenticate Without Reusable Plaintext Passwords (2.12.8)
> Ability to Define Privilege Levels (2.12.10)
> Ability to Assign Privilege Levels to Users (2.12.11)
> Default Privilege Level Must Be Read Only (2.12.12)
> Change in Privilege Levels Requires Re-Authentication (2.12.13)
> Accounting Records (2.12.14)
>
> Vendor Behavior
> Vendor Responsiveness (2.14.1)
>
>
> A.2 Layer 3 Network Core Profile
>
> This section builds on the minimal requirements listed in A.1 and
> adds more stringent security functionality specific to layer 3 devices
> which are part of the network core. The network core devices need to
> be as free as possible from features which affect high-speed packet
> forwarding so the security requirements fall mostly into the category
> of making sure there is functionality to trace attacks and to ‘hide’
> the actual device from potential intruders.
>
> IP Stack Requirements
> Support Denial of Service Tracking (3.3.1)
> Traffic Monitoring (3.3.2)
> Traffic Sampling (3.3.3)
> Ability To Stealth Device (4.1.1)

Note that all of these are in the current "non-standard" or
"advanced" reqs, which could no way be called BCP yet.
Not sure if we can include them.

>
>
> A.3 Layer 3 Network Edge Profile
>
> This section builds on the minimal requirements listed in A.1 and adds
> more stringent security functionality specific to layer 3 devices which
> are part of the network edge. The network edge is typically where much
> of the filtering and traffic control policies are implemented.
>
> Rate Limiting
> Support Rate Limiting (2.4.1)
> Support Rate Limiting Based on State (2.4.2)
>
> Filtering
> Ability to Filter Traffic (2.5)
> Ability to Filter on Addresses (2.6.2)
> Ability to Filter on Any Protocol Header Field (2.6.3)
> Ability to Filter Traffic Through the Device (2.7.1)
> Ability to Filter Traffic to the Device (2.7.2)

Filtering TO is a minimum req. See yesterday's CERT:
http://www.cert.org/advisories/CA-2003-15.html for reason.

filteirng THROUGH is an edge req...which means that most of the other
filtering reqs will move to basic.

> Ability to Accurately Count Filter Hits (2.9.1)
> Ability to Filter Without Performance Degredation (2.10.3)
>
> Event Logging
> Ability to Log All Events That Affect System Integrity (2.11.1)
> Ability to Log To Remote Server (2.11.4)
> Ability to Log Locally (2.11.7)
>
> IP Stack Requirements
> Support Denial of Service Tracking (3.3.1)
> Traffic Monitoring (3.3.2)
> Traffic Sampling (3.3.3)

See previous comments on non BCPness.


> A.4 Layer 2 Network Core Profile
>
> This section builds on the minimal requirements listed in A.1 and adds
> more stringent security functionality specific to layer 2 devices which
> are part of the network core.
>
> VLAN Isolation (2.13.2)
> Layer 2 Denial of Service (2.13.3)
> Layer 3 Dependencies (2.13.4)
>
>
>
> A.5 Layer 2 Edge Profile
>
> This section builds on the minimal requirements listed in A.1 and adds more
> stringent security functionality specific to layer 2 devices which are part
> of the network edge. The network edge is typically where much of the filtering
> and traffic control policies are implemented so more emphasis on this is added
> to the security profile.
>
> Ability to Filter on Layer 2 MAC Addresses (2.6.5)
> Filtering MPLS LSRs (2.13.1)
> VLAN Isolation (2.13.2)
> Layer 2 Denial of Service (2.13.3)
> Layer 3 Dependencies (2.13.4)
>
>
>
> A.5 SOHO Profile
>
> SOHO devices are simple IP devices which are located in small offices or people’s

^^^^^^
> homes. These include cable modems, dsl modems and small routers. All of these
^^^^^^

s/people's//

> may have embedded layer 2 switch technology and some may even act as wireless access
> points. Wireless equipment have their own set of security requirements which are
> addressed in the next section.
>
> SOHO devices are typically configured once and left alone. These devices have
> exactly one profile which needs to be met which is largely a subset of the minimal
> requirements listed in appendix A. The main goal of this security profile is to make
> sure these devices are configured at start-up with defaults which will provide a
> reasonable level of security to avoid these devices from becoming simple targets
> for botnet searchers.
^^^^^^^^^^^^^^^^

more generic wording needed.

> (Functionality not yet listed in document)
> No default passwords
> Must configure passwords for access

In unpublished edits.

>
> IP Stack
> Comply with Relevant IETF RFCs on all Protocols Implemented (2.3.1)
> Ability to Identify All Listening Services (2.3.4)
> Ability to Disable Any and All Services (2.3.5)
> Ability to Control Service Bindings for Listening Services (2.3.6)
> Ability to Control Service Source Address (2.3.7)
> Ability to Withstand Well-Known Attacks and Exploits (2.3.8)
>
> Event Logging
> Ability to Log All Events That Affect System Integrity (2.11.1)
>
> AAA
> Authenticate all User Access (2.12.1)
> Support Authentication of Individual Users (2.12.2)
> Support Centralized Authentication (2.12.5)
> Support Local User Authentication (2.12.6)
> Ability to Authenticate Without Reusable Plaintext Passwords (2.12.8)
> Default Privilege Level Must Be Read Only (2.12.12)

Filter TO

>
> Vendor Behavior
> Vendor Responsiveness (2.14.1)
>
>
>
>
> A.6 Wireless Network Device Profile
>
> Wireless networks must be thought of being a free-for all where almost
> anyone can easily eavesdrop on the network. Therefore, it has it’s own
> set of security requirements, which mostly is a subset of the minimal
> security requirements listed in A.1.
>
> (Functionality not listed in core doc)
> Must use WEP
> Must use authentication
> Must use MAC address filtering
> Should use TKIP and 802.11x where possible (most devices should now
> implement it since the standard is ratified…..probably should
> require vendors to have this)

Can you take a stab at writing these (the reqs) up ?