Operational Security Requirements (opsec) BOF or

1
Operational Security Requirements (opsec)
BOForGive Us The Knobs We Need

• July 17, 2003
• George M. Jones ltgmjones_at_mitre.orggt
• opsec_at_ops.ietf.org (mailing list)

2
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

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 _at_ IETFs 5556

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 gt
  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 gt
Conditional, Functional 2.1.5 Device Remains
Manageable at All Times gt drop (too
generic) 2.1.6 Support Remote Configuration
Backup gt Minimum, Functional 2.1.7 Support
Management Over Slow Links gt 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 gt Minimum, Functional
(borrow from T1M1 ?) 3.1.5 Support Scripting of
Management Functions gt 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 gt Minimum,
Functional
23
Overview User Interface Reqs (2)

• Non-standard

3.2.1 Display All Configuration Settings gt
??? (valid reeasons not to expose all)
24
Overview IP Stack Reqs (1)

• BCP

2.3.1 Comply With Relevant IETF RFCs on All
Protocols ... gt 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 gt 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 gt
Minimum, Assurance
25
Overview IP Stack Reqs (2)

• BCP

2.3.9 Maintain Primary Function at All
Times gt 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 gt
Conditional, Functional 2.3.12 Ability to
Disable Directed Broadcasts gt Minimum,
Functional 2.3.13 Identify Origin of IP
Stack 2.3.14 Identify Origin of Operating
System 2.3.13-2.3.14 gt 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 gt ???
27
Overview IP Stack Reqs (4)

• Advanced

4.1.1 Ability To Stealth Device gt
drop/possible spinoff
28
Overview Rate Limiting Reqs

• BCP

2.4.1 Support Rate Limiting 2.4.2 Support
Rate Limiting Based on State gt 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. gt minimum,
functional 2.7 Packet Filtering Application
Targets 2.7.1 Ability to Filter Traffic Through
the Device gt conditional, functional 2.7.2
Ability to Filter Traffic to the Device gt
minimum, functional
30
Overview Filtering Reqs (2)

• BCP

2.7.3 Ability to Filter Updates gt
conditional, functional 2.8 Packet Filtering
Actions 2.8.1 Ability to Specify Filter
Actions gt 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. gt 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 gt
minimum, functional 2.10.4 Filter, Counters, and
Filter Log Performance Must Be Usable gt drop,
too general
33
Overview Logging Reqs (1)

• BCP

2.11.1 Ability to Log All Events That Affect
System Integrity gt 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.13gt 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
gt 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 gt 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 gt
conditional, functional
38
Overview Vendor Behaviour Reqs

• BCP

2.14.1 Vendor Responsiveness gt 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_at_ops.ietf.org, to subscribe
  echo 'subscribe opsec' mail \
  majordomo_at_ops.ietf.org
• Archives _at_ http//ops.ietf.org/lists/opsec/
• Continued feedback/comments welcome.