Operational Security Requirements (opsec) BOF or “Give Us The Knobs We Need” July 17, 2003 George M. Jones (mailing list)

Agenda ● Welcome and discussion of agenda (5 min.) ● Goals (5 min.) ● History and Current Status (10 min.) ● Related Work/”Liaison” [Lonvick,Ziring] (20 min) ● Overview of draft (30 min.) ● Profiles [Kaeo] (10 min) ● Discuss Contents of the draft (30 min.) ● Next Steps, Work Areas, Milestones (10 min.) ● Adjourn

Goals ● Goals: The End Game – Devices that can be deployed in a secure fashion, or “Give us the knobs we need” – A tool to aid communicating security needs – A guide to testing ● Methods: – Published document – Citeable in RFPs

Goals ● Goals: Today – Feedback on resolving tensions – Feedback on the substance of the document – Advice on most useful path to proceed – Identify liaisons with other areas – Identifying people interested in contributing

History and Current Status (1) ● Originally a UUNET testing document ● Used as the basis for security qualifications, mostly backbone and edge devices. ● Tired of vendors bringing in boxes that could not be operationally secured ● Tired of hearing “but you're the only one who wants...” ● Decided to get feedback and publish

History and Current Status (2) ● It was thought that many of the requirements where general or generalizable. ● Much musing about scope. Heritage and operating assumptions still show. ● Several restructurings (profiles, etc.) and reformatting (xml2rfc) ● Several rounds of internal review, some external comment. ● Some informal IETFs 55+56

History and Current Status (3) ● Assembling a team of “section editors” ● -00 draft published, trial balloon ● Collecting comments, will go to -01 and possibly -02, then decide where to go (input please)

History and Current Status (4) ● Major Tensions – Scope (core, edge vs. SOHO, Wireless, special purpose/embedded vs. general purpose) – Operational environment(s)/profiles (OoB vs. Inband) – BCP vs. “near term futures” (ex. Syslog, netconf) – BCP vs. “way out there” (stealthing, sampling) – Overlap with other work – Structure (BCP vs. other, functional/assurance/doc, profiles) – Size (65 pages and counting)

Resolving Tensions (1) ● Resolving the tensions (pre-BOF thoughts) – Scope: Re-narrow focus to large network infrastructure (routers, switches, other managed infrastructure devices). Allow “profiles” for other devices that are proper subsets of reqs. (e.g. SOHO, firewalls, VPN), but add no specific reqs for them. Out of scope: general purpose hosts (incl name/time/log-servers, IDS, etc.), unmanaged devices, mobile devices, etc.

Resolving Tensions (2) ● Resolving the tensions (pre-BOF thoughts) – Split OoB and In-band management reqs, allow choice – “Mostly BCP”....drop “Advanced” (==stealthing).... but what to do about things that are not standards, but “close” that solve problems (syslog, netconf, etc.) ? – Overlap w/other work: discuss in BOF. – Structure: proposed restructuring described later. – Size: No solution in sight.

Related Work (1) ● Related Efforts – IETF – Netconf – syslog – Forces ● Related Efforts – Non-IETF – Common Criteria – ANSI/T1M1 (management, etc.) – ANSI/T1S1 (control plane) ● Other ?

Related Work (2) – “Liaison” Reports “Liaison” reports from related efforts are included here to provide perspective, point to possible sources of ideas, point to possible areas of collaboration. ● Common Criteria ● ANSI/T1M1

Comparison of Requirements Docs

Overview: Goal ● Goal [current]: “The goal of this document is to define a list of security requirements for devices that implement Internet Protocol (IP). The intent of the list is to provide consumers of IP devices a clear, concise way of communicating their security requirements to equipment vendors.” ● Goal [proposed]: “The goal of this document is to define a list of operational security requirements for network infrastructure devices that implement Internet Protocol (IP). The intent...”

Overview: Scope (1) ● Scope [current]: “These requirements apply to devices that make up the network core infrastructure (such as routers and switches) as well other devices that implement IP (e.g., cable modems, personal firewalls,hosts)”

Overview: Scope (2) ● Scope [proposed]: “These requirements apply to devices, such as routers and switches, that make up the IP enabled infrastructure of large networks. It may be possible to define profiles (subsets) of the requirements that apply to broader classes of devices, e.g. security devices, firewalls, mobile devices, or even general purpose hosts, but the list of requirements from which the profiles are drawn will not be extended to cover other unique needs they may have.

Overview: Current Structure ● Current Structure – BCP Reqs – Non-Standard Reqs – Advanced Reqs – Profiles

Overview: Current Major Sections draft-jones-opsec-00.txt ● Device Management ● User Interface ● IP Stack ● Rate Limiting ● Filtering ● Logging ● AAA ● Layer 2 Reqs ● Vendor Behaviour ● Profiles

Overview: Proposed Structure ● Minimum Requirements – Functional ● Device Management... – Documentation – Assurance ● Conditional Requirements – Functional – Documentation – Assurance ● Profiles

Overview: Management Reqs (1) Requirement #s (1.2.3) listed from -00 draft. Possible disposition in -01 indicated by “==> action/placement” (discussion, please) ● BCP Support Out-of-Band Management (OoB) Interfaces Enforce Separation of Data and Control Channels Separation Not Achieved by Filtering No Forwarding Between Management and Data Planes ==> Conditional, Functional Device Remains Manageable at All Times ==> drop (too generic) Support Remote Configuration Backup ==> Minimum, Functional Support Management Over Slow Links ==> Minimum, Functional

Overview: Management Reqs (2) ● Non-Standard Support Secure Management Channels Use Non-Proprietary Encryption Use Strong Encryption Key Management Must Be Scalable ==> Minimum, Functional (borrow from T1M1 ?) Support Scripting of Management Functions ==> Minimum, Functional (netconf ?)

Overview: User Interface Reqs (1) Support Human-Readable Configuration File Display of 'Sanitized' Configuration ==> Minimum, Functional ● BCP

Overview: User Interface Reqs (2) Display All Configuration Settings ==> ??? (valid reeasons not to expose all) ● Non-standard

Overview: IP Stack Reqs (1) ● BCP Comply With Relevant IETF RFCs on All Protocols... ==> minimum, functional Provide a List of All Protocols Implemented Provide Documentation for All Protocols Implemented ==> minimum, documentation Ability to Identify All Listening Services Ability to Disable Any and All Services Ability to Control Service Bindings for Listening Services Ability to Control Service Source Address Ability to Withstand Well-Known Attacks and Exploits ==> Minimum, Assurance

Overview: IP Stack Reqs (2) ● BCP Maintain Primary Function at All Times ==> drop. Too generic Support Automatic Anti-spoofing for Single-Homed Networks Ability to Disable Processing of Packets Utilizing IP Options ==> Conditional, Functional Ability to Disable Directed Broadcasts ==> Minimum, Functional Identify Origin of IP Stack Identify Origin of Operating System ==> Minimum, Assurance

Overview: IP Stack Reqs (3) ● Non-standard Support Denial-Of-Service (DoS) Tracking Traffic Monitoring Traffic Sampling ==> ???

Overview: IP Stack Reqs (4) ● Advanced Ability To Stealth Device ==> drop/possible spinoff

Overview: Rate Limiting Reqs ● BCP Support Rate Limiting Support Rate Limiting Based on State ==> conditional, functional

Overview: Filtering Reqs (1) ● BCP 2.6 Packet Filtering Criteria Ability to Filter on Protocols Ability to Filter on Addresses Ability to Filter on Any Protocol Header Fields Ability to Filter Inbound and Outbound Ability to Filter on Layer 2 MAC Addresses 2.6.* ==> minimum, functional 2.7 Packet Filtering Application Targets Ability to Filter Traffic Through the Device ==> conditional, functional Ability to Filter Traffic to the Device ==> minimum, functional

Overview: Filtering Reqs (2) ● BCP Ability to Filter Updates ==> conditional, functional 2.8 Packet Filtering Actions Ability to Specify Filter Actions ==> minimum, functional

Overview: Filtering Reqs (3) ● BCP 2.9 Packet Filtering Counter Requirements Ability to Accurately Count Filter Hits Ability to Display Filter Counters Ability to Display Filter Counters per Rule Ability to Display Filter Counters per Filter Application Ability to Reset Filter Counters Filter Counters Must Be Accurate 2.9.* ==> minimum, functional

Overview: Filtering Reqs (4) ● BCP 2.10 Other Packet Filtering Requirements Ability to Log Filter Actions Ability to Specify Filter Log Granularity Ability to Filter Without Performance Degradation ==> minimum, functional Filter, Counters, and Filter Log Performance Must Be Usable ==> drop, too general

Overview: Logging Reqs (1) ● BCP Ability to Log All Events That Affect System Integrity ==> minimum, functional... also area for spinoff.

Overview: Logging Reqs (2) ● BCP Logging Facility Conforms to Open Standards Catalog of Log Messages Available Ability to Log to Remote Server Ability to Select Reliable Delivery Ability to Configure Security of Log Messages Ability to Log Locally Ability to Specify Log servers by Event Classification Ability to Classify Events Ability to Maintain Accurate System Time Logs Must Be Timestamped Logs Contain Untranslated Addresses Logs Do Not Contain DNS Names by Default ==> minimum, functional

Overview: AAA Reqs (1) ● BCP Authenticate All User Access Support Authentication of Individual Users Support Simultaneous Connections Ability to Disable All Local Accounts Support Centralized User Authentication Support Local User Authentication Support Configuration of Order of Authentication Methods Ability to Authenticate Without Reusable Plain-text Passwords Support Device-to-Device Authentication – ==> minimum, functional

Overview: AAA Reqs (2) ● BCP Ability to Define Privilege Levels Ability to Assign Privilege Levels to Users Default Privilege Level Must Be Read Only Change in Privilege Levels Requires Re- Authentication Accounting Records – ==> minimum, functional

Overview: Layer 2 Reqs ● BCP Filtering MPLS LSRs VLAN Isolation Layer 2 Denial-of-Service Layer 3 Dependencies – ==> conditional, functional

Overview: Vendor Behaviour Reqs ● BCP Vendor Responsiveness ==> assurance, possible spinoff of metrics group/work.

Overview: Profiles A.1 Minimum Requirements Profile A.2 Layer 3 Network Core Profile A.3 Layer 3 Network Edge Profile A.4 Layer 2 Network Core Profile A.5 Layer 2 Edge Profile

Overview: Recap of Major Sections ● Device Management ● User Interface ● IP Stack ● Rate Limiting ● Filtering ● Logging ● AAA ● Layer 2 Reqs ● Vendor Behaviour ● Profiles

Work Areas ● Resolve tensions (for discussion now) – Scope – Structure – Operational assumptions – BCP vs. non-BCP – Relationship to other efforts (IETF and non-IETF) ● Simplify compound requirements ● Refine profiles

Next Steps and Milestones ● Incorporate feedback from BOF, list ● Restructure, adjust scope, goals if needed ● Publish -01 (August, 2003) ● Solicit more feedback from NANOG, other sources (operators). ● Publish -02 (November, 2003) ● Decide on future direction WRT ANSI/T1, CC ● Publish Informational RFC, merge with ANSI/T1, form Working Group(s).

Adjourn ● Mailing List: to subscribe: “echo 'subscribe opsec' | mail \ ● ● Continued feedback/comments welcome.