[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Less is more
On the theory that "less is more", I'm considering dropping a number
of the requirements that are not clearly in the BCP camp. In the TOC
below (from the -01 doc,
http://www.port111.com/opsec/draft-jones-opsec-01.txt, still waiting
on I-D editor to publish on IETF site), I've marked the ones that will
stay with a "B" (BCP) in first column, and the ones that will go with
an "O" (Other).
Requirements are listed as "O" for one of several reasons: they are not
widespread "current" practices, they are or should be the subject of a
working group/document on their own, they would need a good deal more
definition/work, or it would be difficult to get consensus on them
quickly.
Please have a look and comment. I can be convinced to move things
between the two groups.
Next week, I will likely split the document into two, with one being
the consensus BCP items, and the other an informational doc giving
ideas for future work.
Thanks,
---George Jones
2. Functional Requirements . . . . . . . . . . . . . . . . . 8
2.1 Device Management Requirements . . . . . . . . . . . . . . 8
B 2.1.1 Support Secure Management Channels . . . . . . . . . . . . 8
B 2.1.2 Support Remote Configuration Backup . . . . . . . . . . . 9
B 2.1.3 Support Remote Configuration Restore . . . . . . . . . . . 9
B 2.1.4 Support Management Over Slow Links . . . . . . . . . . . . 10
B 2.1.5 Support Scripting of Management Functions . . . . . . . . 10
O 2.1.6 Restrict Management to Local Interfaces . . . . . . . . . 11
2.2 In-Band Management Requirements . . . . . . . . . . . . . 11
B 2.2.1 Use Non-Proprietary Encryption . . . . . . . . . . . . . . 12
B 2.2.2 Use Strong Encryption . . . . . . . . . . . . . . . . . . 12
O 2.2.3 Key Management Must Be Scalable . . . . . . . . . . . . . 13
2.3 Out-of-Band (OoB) Management Requirements . . . . . . . . 13
B 2.3.1 Support Out-of-Band Management (OoB) Interfaces . . . . . 13
O 2.3.2 Enforce Separation of Data and Management Channels . . . . 14
O 2.3.3 Separation Not Achieved by Filtering . . . . . . . . . . . 14
O 2.3.4 No Forwarding Between Management and Data Planes . . . . . 15
2.4 User Interface Requirements . . . . . . . . . . . . . . . 15
B 2.4.1 Support Human-Readable Configuration File . . . . . . . . 15
O 2.4.2 Display of 'Sanitized' Configuration . . . . . . . . . . . 15
O 2.4.3 Display All Configuration Settings . . . . . . . . . . . . 16
2.5 IP Stack Requirements . . . . . . . . . . . . . . . . . . 17
B 2.5.1 Ability to Identify All Listening Services . . . . . . . . 17
B 2.5.2 Ability to Disable Any and All Services . . . . . . . . . 17
B 2.5.3 Ability to Control Service Bindings for Listening
B Services . . . . . . . . . . . . . . . . . . . . . . . . . 18
B 2.5.4 Ability to Control Service Source Address . . . . . . . . 18
B 2.5.5 Support Automatic Anti-spoofing for Single-Homed
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 19
O 2.5.6 Ability to Disable Processing of Packets Utilizing IP
O Options . . . . . . . . . . . . . . . . . . . . . . . . . 19
B 2.5.7 Directed Broadcasts Disabled by Default . . . . . . . . . 20
O 2.5.8 Support Denial-Of-Service (DoS) Tracking . . . . . . . . . 20
O 2.5.9 Traffic Monitoring . . . . . . . . . . . . . . . . . . . . 21
O 2.5.10 Traffic Sampling . . . . . . . . . . . . . . . . . . . . . 22
B 2.6 Rate Limiting Requirements . . . . . . . . . . . . . . . . 23
B 2.6.1 Support Rate Limiting . . . . . . . . . . . . . . . . . . 23
B 2.6.2 Support Rate Limiting Based on State . . . . . . . . . . . 24
B 2.7 Basic Filtering Capabilities . . . . . . . . . . . . . . . 24
B 2.7.1 Ability to Filter Traffic . . . . . . . . . . . . . . . . 24
B 2.7.2 Ability to Filter Traffic to the Device . . . . . . . . . 25
B 2.7.3 Ability to Filter Traffic Through the Device . . . . . . . 25
B 2.7.4 Ability to Filter Updates . . . . . . . . . . . . . . . . 25
B 2.7.5 Ability to Specify Filter Actions . . . . . . . . . . . . 26
B 2.7.6 Ability to Log Filter Actions . . . . . . . . . . . . . . 27
O 2.7.7 Ability to Filter Without Performance Degradation . . . . 27
2.8 Packet Filtering Criteria . . . . . . . . . . . . . . . . 28
B 2.8.1 Ability to Filter on Protocols . . . . . . . . . . . . . . 28
B 2.8.2 Ability to Filter on Addresses . . . . . . . . . . . . . . 28
B 2.8.3 Ability to Filter on Any Protocol Header Fields . . . . . 28
B 2.8.4 Ability to Filter Inbound and Outbound . . . . . . . . . . 29
O 2.8.5 Ability to Filter on Layer 2 MAC Addresses . . . . . . . . 29
2.9 Packet Filtering Counter Requirements . . . . . . . . . . 30
B 2.9.1 Ability to Accurately Count Filter Hits . . . . . . . . . 30
B 2.9.2 Ability to Display Filter Counters . . . . . . . . . . . . 30
B 2.9.3 Ability to Display Filter Counters per Rule . . . . . . . 31
B 2.9.4 Ability to Display Filter Counters per Filter
Application . . . . . . . . . . . . . . . . . . . . . . . 31
B 2.9.5 Ability to Reset Filter Counters . . . . . . . . . . . . . 32
B 2.9.6 Filter Counters Must Be Accurate . . . . . . . . . . . . . 32
2.10 Other Packet Filtering Requirements . . . . . . . . . . . 32
B 2.10.1 Filter, Counters, and Filter Log Performance Must Be
B Usable . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B 2.10.2 Ability to Specify Filter Log Granularity . . . . . . . . 33
2.11 Event Logging Requirements . . . . . . . . . . . . . . . . 34
O 2.11.1 Ability to Log All Events That Affect System Integrity . . 34
B 2.11.2 Logging Facility Conforms to Open Standards . . . . . . . 34
B 2.11.3 Ability to Log to Remote Server . . . . . . . . . . . . . 35
O 2.11.4 Ability to Select Reliable Delivery . . . . . . . . . . . 35
B 2.11.5 Ability to Log Locally . . . . . . . . . . . . . . . . . . 35
B 2.11.6 Ability to Maintain Accurate System Time . . . . . . . . . 36
B 2.11.7 Logs Must Be Timestamped . . . . . . . . . . . . . . . . . 36
B 2.11.8 Logs Contain Untranslated Addresses . . . . . . . . . . . 37
O 2.11.9 Logs Do Not Contain DNS Names by Default . . . . . . . . . 37
2.12 Authentication, Authorization, and Accounting (AAA)
Requirements . . . . . . . . . . . . . . . . . . . . . . . 38
B 2.12.1 Authenticate All User Access . . . . . . . . . . . . . . . 38
B 2.12.2 Support Authentication of Individual Users . . . . . . . . 38
B 2.12.3 Support Simultaneous Connections . . . . . . . . . . . . . 39
B 2.12.4 Ability to Disable All Local Accounts . . . . . . . . . . 39
B 2.12.5 Support Centralized User Authentication . . . . . . . . . 39
B 2.12.6 Support Local User Authentication . . . . . . . . . . . . 40
B 2.12.7 Support Configuration of Order of Authentication
B Methods . . . . . . . . . . . . . . . . . . . . . . . . . 40
B 2.12.8 Ability to Authenticate Without Reusable Plaintext
B Passwords . . . . . . . . . . . . . . . . . . . . . . . . 41
B 2.12.9 No Default Static Authentication Tokens (Passwords) . . . 42
B 2.12.10 Static Authentication Tokens (Passwords) Must Be
B Configured . . . . . . . . . . . . . . . . . . . . . . . . 42
O 2.12.11 Enforce Selection of Strong Local Static
O Authentication Tokens (Passwords) . . . . . . . . . . . . 43
O 2.12.12 Support Device-to-Device Authentication . . . . . . . . . 43
B 2.12.13 Ability to Define Privilege Levels . . . . . . . . . . . . 44
B 2.12.14 Ability to Assign Privilege Levels to Users . . . . . . . 44
B 2.12.15 Default Privilege Level Must Be Read Only . . . . . . . . 45
B 2.12.16 Change in Privilege Levels Requires Re-Authentication . . 45
B 2.12.17 Accounting Records . . . . . . . . . . . . . . . . . . . . 45
2.13 Layer 2 Requirements . . . . . . . . . . . . . . . . . . . 46
O 2.13.1 Filtering MPLS LSRs . . . . . . . . . . . . . . . . . . . 46
O 2.13.2 VLAN Isolation . . . . . . . . . . . . . . . . . . . . . . 47
O 2.13.3 Layer 2 Denial-of-Service . . . . . . . . . . . . . . . . 47
B 2.13.4 Layer 3 Dependencies . . . . . . . . . . . . . . . . . . . 48
3. Documentation Requirements . . . . . . . . . . . . . . . . 49
O 3.1 Document Listening Services . . . . . . . . . . . . . . . 49
O 3.2 Provide a List of All Protocols Implemented . . . . . . . 49
O 3.3 Provide Documentation for All Protocols Implemented . . . 50
O 3.4 Catalog of Log Messages Available . . . . . . . . . . . . 50
4. Assurance Requirements . . . . . . . . . . . . . . . . . . 51
O 4.1 Ability to Withstand Well-Known Attacks and Exploits . . . 51
O 4.2 Vendor Responsiveness . . . . . . . . . . . . . . . . . . 52
B 4.3 Comply With Relevant IETF RFCs on All Protocols
Implemented . . . . . . . . . . . . . . . . . . . . . . . 52
B 4.4 Identify Origin of IP Stack . . . . . . . . . . . . . . . 54
B 4.5 Identify Origin of Operating System . . . . . . . . . . . 54