operational security requirements (opsec) bof or “give us the knobs we need” july 17, 2003...

Operational Security Requirements (opsec) BOF

or“Give Us The Knobs We Need”

July 17, 2003George 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


● 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


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


● 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 DocsCC/R&S Profile ANSI/T1 OPSEC

Produced By NSA T1 UUNET/gmj/manyAudience Device vendors IP netops, vendorGoal Security Sec. Mgt, etc. Secure ops.Scope IP & ATM Telecom infra. IP Infra.Target(s) Vendors Telecom infra. Routers, switchesStatus Certified Published Std. WIPPublished by NIAP ANSI/T1 IETFCosts 0?? 0/participationWho Certifies ? Certified lab ?? 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 Sectionsdraft-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)

● BCP2.1.1 Support Out-of-Band Management (OoB) Interfaces2.1.2 Enforce Separation of Data and Control Channels2.1.3 Separation Not Achieved by Filtering2.1.4 No Forwarding Between Management and Data Planes

2.1.1-2.1.4 ==> Conditional, Functional2.1.5 Device Remains Manageable at All Times

==> drop (too generic)2.1.6 Support Remote Configuration Backup

==> Minimum, Functional2.1.7 Support Management Over Slow Links

==> Minimum, Functional

Overview: Management Reqs (2)

● Non-Standard3.1.1 Support Secure Management Channels3.1.2 Use Non-Proprietary Encryption3.1.3 Use Strong Encryption3.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)

2.2.1 Support Human-Readable Configuration File2.2.2 Display of 'Sanitized' Configuration

2.2.1-2.2.2 ==> Minimum, Functional

● BCP

Overview: User Interface Reqs (2)

3.2.1 Display All Configuration Settings==> ??? (valid reeasons not to expose all)

● Non-standard

Overview: IP Stack Reqs (1)

● BCP2.3.1 Comply With Relevant IETF RFCs on All Protocols ...

==> minimum, functional2.3.2 Provide a List of All Protocols Implemented2.3.3 Provide Documentation for All Protocols Implemented

2.3.2-2.3.2 ==> minimum, documentation2.3.4 Ability to Identify All Listening Services2.3.5 Ability to Disable Any and All Services2.3.6 Ability to Control Service Bindings for Listening Services2.3.7 Ability to Control Service Source Address

2.3.4-2.3.72.3.8 Ability to Withstand Well-Known Attacks and Exploits

==> Minimum, Assurance


● BCP2.3.9 Maintain Primary Function at All Times

==> drop. Too generic.2.3.10 Support Automatic Anti-spoofing for Single-Homed Networks2.3.11 Ability to Disable Processing of Packets Utilizing IP Options

2.3.10-2.3.11 ==> Conditional, Functional2.3.12 Ability to Disable Directed Broadcasts

==> Minimum, Functional2.3.13 Identify Origin of IP Stack2.3.14 Identify Origin of Operating System

2.3.13-2.3.14 ==> Minimum, Assurance


● Non-standard3.3.1 Support Denial-Of-Service (DoS) Tracking3.3.2 Traffic Monitoring3.3.3 Traffic Sampling

==> ???


● Advanced4.1.1 Ability To Stealth Device

==> drop/possible spinoff

Overview: Rate Limiting Reqs

● BCP2.4.1 Support Rate Limiting2.4.2 Support Rate Limiting Based on State

==> conditional, functional

Overview: Filtering Reqs (1)

● BCP2.6 Packet Filtering Criteria2.6.1 Ability to Filter on Protocols2.6.2 Ability to Filter on Addresses2.6.3 Ability to Filter on Any Protocol Header Fields2.6.4 Ability to Filter Inbound and Outbound2.6.5 Ability to Filter on Layer 2 MAC Addresses

2.6.* ==> minimum, functional2.7 Packet Filtering Application Targets2.7.1 Ability to Filter Traffic Through the Device

==> conditional, functional2.7.2 Ability to Filter Traffic to the Device

==> minimum, functional


● BCP2.7.3 Ability to Filter Updates

==> conditional, functional2.8 Packet Filtering Actions2.8.1 Ability to Specify Filter Actions

==> minimum, functional


● BCP2.9 Packet Filtering Counter Requirements2.9.1 Ability to Accurately Count Filter Hits2.9.2 Ability to Display Filter Counters2.9.3 Ability to Display Filter Counters per Rule2.9.4 Ability to Display Filter Counters per Filter Application2.9.5 Ability to Reset Filter Counters2.9.6 Filter Counters Must Be Accurate

2.9.* ==> minimum, functional


● BCP2.10 Other Packet Filtering Requirements2.10.1 Ability to Log Filter Actions2.10.2 Ability to Specify Filter Log Granularity2.10.3 Ability to Filter Without Performance Degradation

==> minimum, functional2.10.4 Filter, Counters, and Filter Log Performance Must Be Usable

==> drop, too general

Overview: Logging Reqs (1)

● BCP2.11.1 Ability to Log All Events That Affect System Integrity

==> minimum, functional ... also area for spinoff.

Overview: Logging Reqs (2)

● BCP2.11.2 Logging Facility Conforms to Open Standards2.11.3 Catalog of Log Messages Available2.11.4 Ability to Log to Remote Server2.11.5 Ability to Select Reliable Delivery2.11.6 Ability to Configure Security of Log Messages2.11.7 Ability to Log Locally2.11.8 Ability to Specify Log servers by Event Classification2.11.9 Ability to Classify Events2.11.10 Ability to Maintain Accurate System Time2.11.11 Logs Must Be Timestamped2.11.12 Logs Contain Untranslated Addresses2.11.13 Logs Do Not Contain DNS Names by Default

2.11.2 - 2.11.13==> minimum, functional

Overview: AAA Reqs (1)

● BCP2.12.1 Authenticate All User Access2.12.2 Support Authentication of Individual Users2.12.3 Support Simultaneous Connections2.12.4 Ability to Disable All Local Accounts2.12.5 Support Centralized User Authentication2.12.6 Support Local User Authentication2.12.7 Support Configuration of Order of Authentication Methods2.12.8 Ability to Authenticate Without Reusable Plain-text Passwords2.12.9 Support Device-to-Device Authentication

2.12.1 – 2.12.9 ==> minimum, functional

Overview: AAA Reqs (2)

● BCP2.12.10 Ability to Define Privilege Levels2.12.11 Ability to Assign Privilege Levels to Users2.12.12 Default Privilege Level Must Be Read Only2.12.13 Change in Privilege Levels Requires Re-Authentication2.12.14 Accounting Records

2.12.10 – 2.12.14 ==> minimum, functional

Overview: Layer 2 Reqs

● BCP2.13.1 Filtering MPLS LSRs2.13.2 VLAN Isolation2.13.3 Layer 2 Denial-of-Service2.13.4 Layer 3 Dependencies

2.13.1 – 2.13.4 ==> conditional, functional

Overview: Vendor Behaviour Reqs

● BCP2.14.1 Vendor Responsiveness

==> assurance, possible spinoff of metrics group/work.

Overview: Profiles

A.1 Minimum Requirements ProfileA.2 Layer 3 Network Core ProfileA.3 Layer 3 Network Edge ProfileA.4 Layer 2 Network Core ProfileA.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: [email protected], to subscribe: “echo 'subscribe opsec' | mail \ [email protected]”

● Archives @ http://ops.ietf.org/lists/opsec/● Continued feedback/comments welcome.

operational security requirements (opsec) bof or “give us the knobs we need” july 17, 2003...

Documents

current status

goalgoal current

edge devices

work areas

unmanaged devices

mobile devices

managed infrastructure

tensions prebof thoughtsscope