1 / 43

Operational Security Requirements (opsec) BOF or “Give Us The Knobs We Need”

July 17, 2003 George M. Jones <gmjones@mitre.org> opsec@ops.ietf.org (mailing list). Operational Security Requirements (opsec) BOF or “Give Us The Knobs We Need”. Welcome and discussion of agenda (5 min.) Goals (5 min.) History and Current Status (10 min.)

yeriel
Télécharger la présentation

Operational Security Requirements (opsec) BOF or “Give Us The Knobs We Need”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. July 17, 2003 George M. Jones <gmjones@mitre.org> opsec@ops.ietf.org (mailing list) Operational Security Requirements (opsec) BOFor“Give Us The Knobs We Need”

  2. 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 Agenda

  3. 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

  4. 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

  5. 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

  6. 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 review @ IETFs 55+56

  7. 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)

  8. 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)

  9. 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.

  10. 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.

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

  12. 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

  13. Comparison of Requirements Docs

  14. 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...”

  15. 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)”

  16. 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.

  17. Overview: Current Structure • Current Structure • BCP Reqs • Non-Standard Reqs • Advanced Reqs • Profiles

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

  19. Overview: Proposed Structure • Minimum Requirements • Functional • Device Management... • Documentation • Assurance • Conditional Requirements • Functional • Documentation • Assurance • Profiles

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

  21. Overview: Management Reqs (2) • Non-Standard 3.1.1 Support Secure Management Channels 3.1.2 Use Non-Proprietary Encryption 3.1.3 Use Strong Encryption 3.1.4 Key Management Must Be Scalable 3.1.1-3.1.4 ==> Minimum, Functional (borrow from T1M1 ?) 3.1.5 Support Scripting of Management Functions ==> Minimum, Functional (netconf ?)

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

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

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

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

  26. Overview: IP Stack Reqs (3) • Non-standard 3.3.1 Support Denial-Of-Service (DoS) Tracking 3.3.2 Traffic Monitoring 3.3.3 Traffic Sampling ==> ???

  27. Overview: IP Stack Reqs (4) • Advanced 4.1.1 Ability To Stealth Device ==> drop/possible spinoff

  28. Overview: Rate Limiting Reqs • BCP 2.4.1 Support Rate Limiting 2.4.2 Support Rate Limiting Based on State ==> conditional, functional

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

  30. Overview: Filtering Reqs (2) • BCP 2.7.3 Ability to Filter Updates ==> conditional, functional 2.8 Packet Filtering Actions 2.8.1 Ability to Specify Filter Actions ==> minimum, functional

  31. Overview: Filtering Reqs (3) • BCP 2.9 Packet Filtering Counter Requirements 2.9.1 Ability to Accurately Count Filter Hits 2.9.2 Ability to Display Filter Counters 2.9.3 Ability to Display Filter Counters per Rule 2.9.4 Ability to Display Filter Counters per Filter Application 2.9.5 Ability to Reset Filter Counters 2.9.6 Filter Counters Must Be Accurate 2.9.* ==> minimum, functional

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

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

  34. Overview: Logging Reqs (2) • BCP 2.11.2 Logging Facility Conforms to Open Standards 2.11.3 Catalog of Log Messages Available 2.11.4 Ability to Log to Remote Server 2.11.5 Ability to Select Reliable Delivery 2.11.6 Ability to Configure Security of Log Messages 2.11.7 Ability to Log Locally 2.11.8 Ability to Specify Log servers by Event Classification 2.11.9 Ability to Classify Events 2.11.10 Ability to Maintain Accurate System Time 2.11.11 Logs Must Be Timestamped 2.11.12 Logs Contain Untranslated Addresses 2.11.13 Logs Do Not Contain DNS Names by Default 2.11.2 - 2.11.13==> minimum, functional

  35. Overview: AAA Reqs (1) • BCP 2.12.1 Authenticate All User Access 2.12.2 Support Authentication of Individual Users 2.12.3 Support Simultaneous Connections 2.12.4 Ability to Disable All Local Accounts 2.12.5 Support Centralized User Authentication 2.12.6 Support Local User Authentication 2.12.7 Support Configuration of Order of Authentication Methods 2.12.8 Ability to Authenticate Without Reusable Plain-text Passwords 2.12.9 Support Device-to-Device Authentication 2.12.1 – 2.12.9 ==> minimum, functional

  36. Overview: AAA Reqs (2) • BCP 2.12.10 Ability to Define Privilege Levels 2.12.11 Ability to Assign Privilege Levels to Users 2.12.12 Default Privilege Level Must Be Read Only 2.12.13 Change in Privilege Levels Requires Re-Authentication 2.12.14 Accounting Records 2.12.10 – 2.12.14 ==> minimum, functional

  37. Overview: Layer 2 Reqs • BCP 2.13.1 Filtering MPLS LSRs 2.13.2 VLAN Isolation 2.13.3 Layer 2 Denial-of-Service 2.13.4 Layer 3 Dependencies 2.13.1 – 2.13.4 ==> conditional, functional

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

  39. 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

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

  41. 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

  42. 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).

  43. Adjourn • Mailing List: opsec@ops.ietf.org, to subscribe: “echo 'subscribe opsec' | mail \ majordomo@ops.ietf.org” • Archives @ http://ops.ietf.org/lists/opsec/ • Continued feedback/comments welcome.

More Related