Transcript Operational Security Requirements (opsec) BOF or “Give Us The

Operational Security
Requirements (opsec) BOF
or
“Give Us The Knobs We Need”
July 17, 2003
George M. Jones <[email protected]>
[email protected] (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 review @ 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)
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
CC/R&S Profile ANSI/T1
Produced By NSA
T1
Audience
Device vendors
Goal
Security
Sec. Mgt, etc.
Scope
IP & ATM
Telecom infra.
Target(s)
Vendors
Telecom infra.
Status
Certified
Published Std.
Published by NIAP
ANSI/T1
Costs
0??
Who Certifies ? Certified lab
??
OPSEC
UUNET/gmj/many
IP netops, vendor
Secure ops.
IP Infra.
Routers, switches
WIP
IETF
0/participation
Self
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
●
Layer 2 Reqs
●
User Interface
●
Vendor Behaviour
●
IP Stack
●
Profiles
●
Rate Limiting
●
Filtering
●
Logging
●
AAA
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)
●
2.1.1
BCP
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
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 ?)
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
Overview: User Interface Reqs (2)
●
Non-standard
3.2.1 Display All Configuration Settings
==> ??? (valid reeasons not to expose all)
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
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
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
==> ???
Overview: IP Stack Reqs (4)
●
Advanced
4.1.1 Ability To Stealth Device
==> drop/possible spinoff
Overview: Rate Limiting Reqs
●
BCP
2.4.1 Support Rate Limiting
2.4.2 Support Rate Limiting Based on
State
==> conditional, functional
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
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
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
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
Overview: Logging Reqs (1)
●
BCP
2.11.1 Ability to Log All Events That Affect System
Integrity
==> minimum, functional ... also area for spinoff.
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
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
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 ReAuthentication
2.12.14 Accounting Records
2.12.10 – 2.12.14 ==> minimum, functional
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
Overview: Vendor Behaviour Reqs
●
BCP
2.14.1 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
●
Layer 2 Reqs
●
User Interface
●
Vendor Behaviour
●
IP Stack
●
Profiles
●
Rate Limiting
●
Filtering
●
Logging
●
AAA
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: [email protected], to
subscribe: “echo 'subscribe opsec' | mail \
[email protected]”
●
Archives @ http://ops.ietf.org/lists/opsec/
●
Continued feedback/comments welcome.