idnits 2.17.1 draft-ietf-sacm-terminology-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 899, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational J. Lu 5 Expires: September 14, 2017 Oracle Corporation 6 J. Strassner 7 Huawei Technologies 8 N. Cam-Winget 9 Cisco Systems 10 March 13, 2017 12 Security Automation and Continuous Monitoring (SACM) Terminology 13 draft-ietf-sacm-terminology-12 15 Abstract 17 This memo documents terminology used in the documents produced by 18 SACM (Security Automation and Continuous Monitoring). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 14, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 59 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 60 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 61 8. Informative References . . . . . . . . . . . . . . . . . . . 25 62 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 26 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 65 1. Introduction 67 Our goal with this document is to improve our agreement on the 68 terminology used in documents produced by the IETF Working Group for 69 Security Automation and Continuous Monitoring. Agreeing on 70 terminology should help reach consensus on which problems we're 71 trying to solve, and propose solutions and decide which ones to use. 73 2. Terms and Definitions 75 This section describes terms that have been defined by other RFC's 76 and defines new ones. The predefined terms will reference the RFC 77 and where appropriate will be annotated with the specific context by 78 which the term is used in SACM. 80 Assertion: Defined by the ITU in [X.1252] as "a statement made by an 81 entity without accompanying evidence of its validity". In the 82 context of SACM, an assertion is the output of a SACM component in 83 the form of a statement (including metadata about the data source 84 and data origin, e.g. time stamps). While the validity of an 85 assertion cannot be verified without, for example, an additional 86 attestation protocol, an assertion (and therfore a statement, 87 respectivly) can be accompanied by evidence of the validity of its 88 metadata provided by a SACM component. 90 Assessment: Defined in [RFC5209] as "the process of collecting 91 posture for a set of capabilities on the endpoint (e.g., host- 92 based firewall) such that the appropriate validators may evaluate 93 the posture against compliance policy." 95 An assessment is a specifc workflow that incorporates the SACM 96 tasks discovery, collection and evaluation. A prominent instance 97 of the assessment workflow is illustrated in the Vulnerability 98 Assessement Scenario [I-D.ietf-sacm-vuln-scenario]. 100 Asset: Defined in [RFC4949] as "a system resource that is (a) 101 required to be protected by an information system's security 102 policy, (b) intended to be protected by a countermeasure, or (c) 103 required for a system's mission". In the scope of SACM, an asset 104 can be composed of other assets. Examples of Assets include: 105 Endpoints, Software, Guidance, or X.509 public key certificates. 106 An asset is not necessarily owned by an organization. 108 Asset Management: The process by which assets are provisioned, 109 updated, maintained and deprecated. 111 Attribute: Defined in [RFC5209] as "data element including any 112 requisite meta-data describing an observed, expected, or the 113 operational status of an endpoint feature (e.g., anti-virus 114 software is currently in use)." In the context of SACM, 115 attributes are "atomic" information elements and an equivalent to 116 attribute-value-pairs. Attributes can be components of Subjects. 118 Authentication: Defined in [RFC4949] as "the process of verifying a 119 claim that a system entity or system resource has a certain 120 attribute value." 122 Authorization: Defined in [RFC4949] as "an approval that is granted 123 to a system entity to access a system resource." 125 Broker: A broker is a specific controller type that contains control 126 plane functions to provide and/or connect services on behalf of 127 other SACM components via interfaces on the control plane. A 128 broker may provide, for example, authorization services and find, 129 upon request, SACM components providing requested services. 131 Capability: In [I-D.ietf-i2nsf-terminology] a capability "defines a 132 set of features that are available from a managed entity. 133 Examples of "managed entities" are NSFs and Controllers, where NSF 134 Capabilities and Controller Capabilities define functionality of 135 an NSF and a Controller that may, but do not have to, be used, 136 respectively. All Capabilities are announced through the 137 Registration Interface." 139 In the context of SACM, the extent of a SACM component's ability 140 is enabled by the functions it is composed of. Capabilities are 141 announced by a SACM component via the SACM component registration 142 task and can be discovered by or negotiated with other SACM 143 components. For example, the capability of a SACM Provider may be 144 to provide endpoint management data, or only a subset of that 145 data. 147 The SACM Vulnerability Assessment Scenario 148 [I-D.ietf-sacm-vuln-scenario] defines the terms Endpoint 149 Management Capabilities, Vulnerability Management Capabilities, 150 and Vulnerability Assessment Capabilities, which illustrate 151 specific sets of SACM capabilities, which are required to conduct 152 workflows illustrated by the scenario definition. 154 Collection Result: Information about a target endpoint that is 155 produced by a collector conducting a collection task. A 156 collection result is composed as one or more content-elements. 158 Collection Task: The task by which endpoint attributes and/or 159 corresponding attribute values about a target endpoint are 160 collected. The collection tasks are targeted at specific target 161 endpoints and therefore are targeted tasks. 163 There are three types of frequency collection tasks can be 164 conducted with: 166 ad-hoc, e.g. triggered by a specific event or a query 168 scheduled, e.g. in regular intervals, such as every minute or 169 weekly 171 continuously, e.g. a network behavior observation 173 There are three types of collection methods, each requiring an 174 appropriate set of functions to be included in the SACM component 175 conducting the collection task: 177 Self-Reporting: A SACM component located on the target endpoint 178 itself conducts the collection task. 180 Remote-Acquisition: A SACM component located on an Endpoint 181 different from the target endpoint conducts the collection task 182 via interfaces available on the target endpoint, e.g. SNMP/ 183 NETCONF or WMI. 185 Behavior-Observation: A SACM component located on an Endpoint 186 different from the target endpoint observes network traffic 187 related to the target endpoint and conducts the collection task 188 via interpretation of that network traffic. 190 Collector: A piece of software that acquires information about one 191 or more target endpoints by conducting collection tasks. A 192 collector provides acquired information in the form of collection 193 results via a set of registered capabilities that can be 194 discovered by other SACM components. 196 A collector can be distributed across multiple endpoints, e.g. 197 across a target endpoint and a SACM component. The separate parts 198 of the collector can communicate with a specialized protocol, such 199 as PA-TNC [RFC5792]. At least one part of a distributed collector 200 has to take on the role of a provider of information by providing 201 SACM interfaces to propagate capabilities and to provide SACM 202 content in the form of collection results. 204 Configuration: A non-volatile subset of the endpoint attributes of a 205 (target) endpoint that is intended to be uneffected by a normal 206 reboot-cylce. Configuration is a type of imperative guidance that 207 is stored in files (files dedicated to contain configuration and/ 208 or files that are software components), directly on block devices, 209 or on specific hardware components that can be accessed via 210 corresponding software components. Modification of configuration 211 can be conducted manually or automatically via management (plane) 212 interfaces that support management protocols, such as SNMP or WMI. 213 A change of configuration can occur during both run-time and down- 214 time of an endpoint. It is common practive to scheduled a change 215 of configuration during or directly after the completion of a 216 boot-cycle via corresponding software components located on the 217 target endpoint itself. 219 Exmaples: The static association of an IP address and a MAC 220 address in a DHCP server configuration, a directory-path that 221 identifies a log-file directory, a registry entry. 223 Configuration Drift: The discrepancy of a target endpoint's endpoint 224 attributes representing the actual composition of a target 225 endpoint (is-state) and its intended composition (should-state) in 226 the scope of a valid target endpoint composition (could-state) due 227 to continuous alteration of a target endpoint's composition over 228 time. Configuration drift exists for both hardware components and 229 software components. Typically, the frequency and scale of 230 configuration drift of software components is significantly higher 231 than the configuration drift of hardware components. 233 Consumer: A consumer is a SACM role that is assigned to a SACM 234 component that contains functions to receive information from 235 other SACM components. 237 Content Element: Content elements constitute the payload data (SACM 238 content) transfered via statement Subjects emitted by providers of 239 information. Every content element Subject includes a specific 240 content Subject and a corresponding content metadata Subject. 242 Content Metadata: Data about content Subjects. Every content- 243 element includes a content metadata Subject. The Subject can 244 include any information element that can annotate the content 245 transefered. Examples include time stamps or data provenance 246 Subjects. 248 Control Plane: Typically used as a term in the context of routing, 249 e.g. [RFC6192]. In the context of SACM, the control plane is an 250 architectural component providing common control functions to all 251 SACM components, including authentication, authorization, 252 (capability) discovery or negotiation, registration and 253 subscription. The control plane orchestrates the flow on the data 254 plane according to imperative guidance (i.e. configuration) 255 received via the management plane. SACM components with 256 interfaces to the control plane have knowledge of the capabilities 257 of other SACM components within a SACM domain. 259 Controller: A controller is a SACM role that is assigned to a SACM 260 component containing control plane functions that manage and 261 facilitate information sharing or execute on security functions. 262 There are three types of SACM controllers: Broker, Proxy, and 263 Repository. Depending on its type, a controller can also contain 264 functions that have interfaces on the data plane. 266 Data Confidentiality: Defined in [RFC4949] as "the property that 267 data is not disclosed to system entities unless they have been 268 authorized to know the data." 270 Data In Motion: Data that is being transported via a network; also 271 referred to as "Data in Transit" or "Data in Flight". Data in 272 motion requires a data model to transfer the data using a specific 273 encoding. Typically, data in motion is serialized (marshalling) 274 into a transport encoding by a provider of information and 275 deserialized (unmarshalling) by a consumer of information. The 276 termination points of provider of information and consumer of 277 information data is transferred between are interfaces. In regard 278 to data in motion, the interpretation of the roles consumer of 279 information and provider of information depends on the 280 corresponding OSI layer (e.g. on layer2: between interfaces 281 connected to a broadcast domain, on layer4: between interfaces 282 that maintain a TCP connection). In the context of SACM, consumer 283 of information and provider of information are SACM components. 285 The SACM architecture and corresponding models focus on data in 286 motion. 288 Data At Rest: Data that is stored in a repository. Data at rest 289 requires a data model to encode the data to be stored. In the 290 context of SACM, data at rest located on a SACM component can be 291 provided to other SACM components via discoverable capabilities. 293 In the context of SACM, data models for data at rest are out of 294 scope. 296 Data Integrity: Defined in [RFC4949] as "the property that data has 297 not been changed, destroyed, or lost in an unauthorized or 298 accidental manner." 300 Data Origin: One or more properties (i.e. endpoint attributes) that 301 enable a SACM component to identify the SACM component that 302 initially acquired or produced data about a (target) endpoint 303 (e.g. via collection from a data source) and made it available to 304 a SACM domaini via a SACM statement. Data Origin can be expressed 305 by an endpoint label information element (e.g. to be used as 306 metadata in statement). 308 Data Plane (fix statement): Typically used as a term in the context 309 of routing (and used as a synonym for forwarding plane, e.g. 310 [RFC6192]). In the context of SACM, the data plane is an 311 architectural component providing operational functions to enable 312 a SACM component to provide and consume SACM statements and 313 therefore SACM content (the "payload"). The data plane is used to 314 conduct distributed SACM tasks by transporting SACM content using 315 transporting encodings and corresponding operations defined by 316 SACM data models. 318 Data Provenance: A historical record of the sources, origins and 319 evolution of data that is influenced by inputs, entities, 320 functions and processes. In the context of SACM, data provenance 321 is expressed as metadata that identifies SACM statements and 322 corresponding content elements a new statement is created from. 323 In a downstream process, this references can cascade, creating a 324 data provenance tree that enables SACM components to trace back 325 the original data sources involved in the creation of SACM 326 statements and take into account their characteristics and 327 trustworthiness. 329 Data Source: One or more properties (i.e. endpoint attributes) that 330 enable a SACM component to identify - and potentially characterize 331 - a (target) endpoint that is claimed to be the original source of 332 endpoint attributes in a SACM statement. Data Source can be 333 expressed as metadata by an endpoint label information element or 334 a corresponding subject of identifying endpoint attributes. 336 Endpoint: Defined in [RFC5209] as "any computing device that can be 337 connected to a network. Such devices normally are associated with 338 a particular link layer address before joining the network and 339 potentially an IP address once on the network. This includes: 340 laptops, desktops, servers, cell phones, or any device that may 341 have an IP address." 343 To further clarify the [RFC5209] definition, an endpoint is any 344 physical or virtual device that may have a network address. Note 345 that, network infrastructure devices (e.g. switches, routers, 346 firewalls), which fit the definition, are also considered to be 347 endpoints within this document. 349 Physical endpoints are always composites that are composed of 350 hardware components and software components. Virtual endpoints 351 are composed entirely of software components and rely on software 352 components that provide functions equivalent to hardware 353 components. 355 The SACM architecture differentiates two essential categories of 356 endpoints: Endpoints whose security posture is intended to be 357 assessed (target endpoints) and endpoints that are specifically 358 excluded from endpoint posture assessment (excluded endpoints). 360 Based on the definition of an asset, an endpoint is a type of 361 asset. 363 Endpoint Attribute: In the context of SACM, endpoint attributes are 364 information elements that describe an endpoint characteristic of a 365 target endpoint. Endpoint Attributes typically constitute 366 Attributes that can be bundled into Subject (e.g. information 367 about a specific network interface can be represented via a set of 368 multiple AVP). 370 Endpoint Characteristic: The state, configuration and composition an 371 endpoint is in, including observerable behavior, e.g. sys-calls, 372 log-files, or PDU emission on a network. 374 Endpoint Characterization: The task by which a profile is composed 375 out of endpoint attributes that describe the desired or expected 376 posture of a type or class of target endpoints or even an 377 individual target endpoint. The result of this task is an 378 endpoint profile that is required as declarative guidance for the 379 tasks of endpoint classification or posture assessment. 381 Endpoint Classification: The task by which a discovered target 382 endpoint is classified. Endpoint classification requires 383 declarative guidance in the form of an endpoint profile, discovery 384 results and potentially collection results. Types, classes or the 385 characteristics of an individual target endpoint are defined via 386 endpoint profiles. 388 Endpoint Label: In a SACM domain, every endpoint can be identified 389 by an endpoint label. There are two prominent uses of endpoint 390 labels in a SACM domain: to identify SACM components and to 391 identify Target Endpoints. Both endpoint labels can be used in 392 SACM content or in content metadata: 394 SACM Components are identified by: SACM component label / Data 395 Origin 397 Target Endpoints are identified by: TE label / Data Source 399 An endpoint label is expressed as an artificially created ID that 400 references a distinct set of identifying attributes (Target 401 Endpoint Identifier). A target endpoint label is unique in a SACM 402 domain and created by a SACM component that provides the 403 appropriate function as a capability. 405 Endpoint Management Capabilities: An enterprise IT department's 406 ability to manage endpoint identity, endpoint information, and 407 associated metadata on an ongoing basis. 409 Evaluation Task: The task by which endpoint attributes are 410 evaluated. 412 Evaluation Result: The resulting value from having evaluated a set 413 of posture attributes. 415 Event: The change of a target endpoint characteristics at a specific 416 point in time. In the context of SACM, an event is a statement 417 (and therefore data in motion) that includes the new target 418 endpoint characteristics and optional also the past ones, 419 annotated with corresponding metedata (most prominently, the 420 collection time of the data that constitutes the observation of 421 the event regarding te target endpoint). 423 Excluded Endpoint: A specific designation, which is assigned to an 424 endpoint that is not supposed to be the subject of a collection 425 task (and therefore is not a target endpoint). Typically but not 426 necessarily, endpoints that contain a SACM component (and are 427 therefore part of the SACM domain) are designated as excluded 428 endpoints. Target endpoints that contain a SACM component cannot 429 be designated as excluded endpoints and are part of the SACM 430 domain. 432 Expected Endpoint State: The required state of an endpoint that is 433 to be compared against. Sets of expected endpoint states are 434 transported as declarative guidance in target endpoint profiles 435 via the management plane. This, for example, can be a policy, but 436 also a recorded past state. An expected state is represented can 437 be represented via an Attribute or an Subject that represents a 438 set of multiple attribute value pairs. 440 SACM Function: A behavioral aspect or capacity of a particular SACM 441 component, which belies that SACM component's purpose. For 442 example, a SACM function with interfaces on the control plane can 443 provide a brokering function to other SACM components. Via data 444 plane interfaces, a function can act as a provider and/or as a 445 consumer of information. SACM functions can be propagated as the 446 capabilities of a SACM component and can be discovered by or 447 negotiated with other SACM components. 449 Guidance: Input instructions to processes, such as automated device 450 management or remediation, and SACM tasks, such as collection or 451 evaluation. Guidance influences the behavior of a SACM component 452 and is considered content of the management plane. In the context 453 of SACM, guidance is machine-readable and can be manually or 454 automatically generated or provided. Typically, the tasks that 455 provide guidance to SACM components have a low-frequency and tend 456 to be be sporadic. 458 There are two types of guidance: 460 Declarative Guidance: defines the configuration or state an 461 endpoint is supposed to be in--without providing specific actions 462 or methods to produce that desired state. Examples include Target 463 Endpoint Profiles or network topology based requirements. 465 Imperative Guidance: prescribes specific actions to be conducted 466 or methods to be used in order to achieve an outcome. Examples 467 include a targeted Collection Task or the IP-Address of a SACM 468 Component that provides a registration function. 470 Hardware Component: Hardware components are the distinguishable 471 physical components that compose an endpoint. The composition of 472 an endpoint can be changed over time by adding or removing 473 hardware components. In essence, every physical endpoint is 474 potentially a composite of multiple hardware components, typically 475 resulting in a hierarchical composition of hardware components. 476 The composition of hardware components is based on interconnects 477 provided by specific hardware types (e.g. mainboard is a hardware 478 type that provides local busses as an interconnect). In general, 479 a hardware component can be distinguished by its serial number. 481 Occasionally, hardware components are refered to as power sucking 482 aliens. 484 Hardware Inventory: The list of hardware components that compose a 485 specific endpoint representing its hardware configuration. 487 Hardware Type: Hardware types define specific and distinguishable 488 categories of hardware components that can be part of endpoints, 489 e.g. CPU or 802.11p interface. Typically, hardware types can be 490 distinguished by their vendor assigned names, names of standards 491 used, or a model name. 493 Information Element: A representation of information about physical 494 and virtual "objects of interests". Information elements are the 495 building blocks that constitute the SACM information model. In 496 the context of SACM, an information element that expresses a 497 single value with a specific name is referred to as an Attribute 498 (analogous to an attribute-value-pair). A set of attributes that 499 is bundled into a more complex composite information element is 500 referred to as a Subject. Every information element in the SACM 501 information model has a unique name. Endpoint attributes or time 502 stamps, for example, are represented as information elements in 503 the SACM information model. 505 Information Model: An information model is an abstract 506 representation of data, their properties, relationships between 507 data and the operations that can be performed on the data. While 508 there is some overlap with a data model, [RFC3444] distinguishes 509 an information model as being protocol and implementation neutral 510 whereas a data model would provide such details. The purpose of 511 the SACM information model is to ensure interoperability between 512 SACM data models (that are used as transport encoding) and to 513 provide a standardized set of information elements for 514 communication between SACM components. 516 Interaction Model: The definition of specific sequences regarding 517 the exchange of messages (data in motion), including, for exmaple, 518 conditional branching, thresholds and timers. An interaction 519 model, for example, can be used to define operations, such as 520 registration or discovery, on the control plane. A composition of 521 data models for data in motion and a corresponding interaction 522 model is a protocol. 524 Internal Collector: Internal Collector: a collector that runs on a 525 target endpoint to acquire information from that target endpoint. 526 (TBD: An internal collector is not a SACM component and therefore 527 not part of a SACM domain). 529 Management Plane: An architectural component providing common 530 functions to steer the behavior of SACM components, e.g. its 531 behavior on the control plane. Prominent examples include: 532 modification of the configuration of a SACM component or updating 533 a target endpoint profile that resides on an evaluator. In 534 essence, guidance is transported via the management plane. 535 Typically, a SACM component can fulfill its purpose without 536 continuous input from the management plane. In contrast, without 537 continuous availability of control plane functions a typical SACM 538 component could not function properly. In general, interaction on 539 the management plane is less frequent and less regular than on the 540 control plane. Input via the management plane can be manual (e.g. 541 via a CLI), or can be automated via management plane functions 542 that are part of other SACM components. 544 Metadata: Data about data. In the SACM information model, data is 545 referred to as Content. Metadata about the content is referred to 546 as Content-Metadata, respectively. Content and Content-Metadata 547 are combined into Subjects called Content-Elements in the SACM 548 information model. Some information elements defined by the SACM 549 information model can be part of the Content or the Content- 550 Metadata. Therefore, if an information element is considered data 551 or data about data depends on which kind of Subject it is 552 associated with. The SACM information model also defines metadata 553 about the data origin via the Subject Statement-Metadata. Typical 554 examples of metadata are time stamps, data origin or data source. 556 Network Address: Network addresses are layer specific and follow 557 layer specific address schemes. Each interface of a specific 558 layer can be associated with one or more addresses appropriate for 559 that layer. There is no guarantee that an address is globally 560 unique. In general, there is a scope to an address in which it is 561 intended to be unique. 563 Examples include: physical Ethernet port with a MAC address, layer 564 2 VLAN interface with a MAC address, layer 3 interface with 565 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 566 IPv4 address. 568 Network Interface: An endpoint is connected to a network via one or 569 more network interfaces. Network interfaces can be physical or 570 virtual. Network interfaces of an endpoint can operate on 571 different layers, most prominently what is now commonly called 572 layer 2 and 3. Within a layer, interfaces can be nested. 574 On layer 2, a root interface is typically associated with a 575 physical interface port and nested interfaces are virtual 576 interfaces. In the case of a virtual endpoint, a root interface 577 can be a virtual interface. Virtual layer 2 interfaces of one or 578 more endpoints can also constitute an aggregated group of links 579 that act as one. 581 On layer 3, nested interfaces typically constitute virtual tunnels 582 or virtual (mesh) networks. 584 Examples include: physical Ethernet port, layer 2 VLAN interface, 585 a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress. 587 Posture: Defined in [RFC5209] as "configuration and/or status of 588 hardware or software on an endpoint as it pertains to an 589 organization's security policy." 591 This term is used within the scope of SACM to represent the 592 configuration and state information that is collected from a 593 target endpoint in the form of endpoint attributes (e.g. software/ 594 hardware inventory, configuration settings, dynamically assigned 595 addresses). This information may constitute one or more posture 596 attributes. 598 Posture Attributes: Defined in [RFC5209] as "attributes describing 599 the configuration or status (posture) of a feature of the 600 endpoint. A Posture Attribute represents a single property of an 601 observed state. For example, a Posture Attribute might describe 602 the version of the operating system installed on the system." 604 Within this document this term represents a specific assertion 605 about endpoint configuration or state (e.g. configuration setting, 606 installed software, hardware) represented via endpoint attributes. 607 The phrase "features of the endpoint" highlighted above refers to 608 installed software or software components. 610 Provider: A provider is a SACM role that is assigned to a SACM 611 component that contains functions to provide information to other 612 SACM components. 614 Proxy: A proxy is a specific controller type that provides data 615 plane and control plane functions, information, or services on 616 behalf of another component, which is not directly participating 617 in the SACM architecture. 619 Repository: A repository is a specific controller type that contains 620 functions to consume, store and provide information of a 621 particular kind - typically data transported on the data plane, 622 but potentially also data and metadata from the control and 623 management plane. A single repository may provide the functions 624 of more than one specific repository type (i.e. configuration 625 baseline repository, assessment results repository, etc.) 627 SACM Component: A component is defined in 628 [I-D.ietf-i2nsf-terminology] as "an encapsulation of software that 629 communicates using Interfaces. A Component may be implemented by 630 hardware and/or Software, and be represented using a set of 631 classes. In general, a Component encapsulates a set of data 632 structures as well as a set of algorithms that implement the 633 functions that it provides." 635 In the context of SACM, a set of SACM functions composes a SACM 636 component. A SACM component conducts SACM tasks, acting on 637 control plane, data plane and/or management plane via 638 corresponding SACM interfaces. SACM defines a set of standard 639 components (e.g. a collector, a broker, or a data store). A SACM 640 component contains at least a basic set of control plane functions 641 and can contain data plane and management plane functions. A SACM 642 component residing on an endpoint assigns one or more SACM roles 643 to the corresponding endpoint due to the SACM functions it is 644 composed of. A SACM component "resides on" an endpoint and an 645 endpoint "contains" a SACM component, correspondingly. For 646 example, a SACM component that is composed solely of functions 647 that provide information would only take on the role of a 648 provider. 650 SACM Component Discovery: The task of brokering appropriate SACM 651 components according to their capabilities or roles on reques. 653 Input: Query 655 Output: a list of SACM components including metadata 657 SACM Component Label: A specific endpoint label that is used to 658 identify a SACM component. In content-metadata, this label is 659 called data origin. 661 SACM Content: The payload provided by SACM components to the SACM 662 domain on the data plane. SACM content includes the SACM data 663 models. 665 SACM Domain: Endpoints that include a SACM component compose a SACM 666 domain. (To be revised, additional definition content TBD, 667 possible dependencies to SACM architecture) 669 SACM Interface: An interface is defined in 670 [I-D.ietf-i2nsf-terminology] as "A set of operations one object 671 knows it can invoke on, and expose to, another object. This 672 decouples the implementation of the operation from its 673 specification. An interface is a subset of all operations that a 674 given object implements. The same object may have multiple types 675 of interfaces to serve different purposes." 677 In the context of SACM, SACM Funktions provide SACM Interfaces on 678 the management, control, or data plane. Operations a SACM 679 Interface provides are based on corresponding data model defined 680 by SACM. SACM Interfaces are used for communication between SACM 681 components. 683 SACM Role: A role is defined in [I-D.ietf-i2nsf-terminology] as "an 684 abstraction of a Component that models context-specific views and 685 responsibilities of an object as separate role objects that can be 686 statically or dynamically attached to (and removed from) the 687 object that the role object describes. This provides three 688 important benefits. First, it enables different behavior to be 689 supported by the same Component for different contexts. Second, 690 it enables the behavior of a Component to be adjusted dynamically 691 (i.e., at runtime, in response)to changes in context, by using one 692 or more Roles to define the behavior desired for each context. 693 Third, it decouples the Roles of a Component from the Applications 694 that use that Component." 696 In the context of SACM, SACM roles are associated with SACM 697 components and are defined by the set of functions and interfaces 698 a SACM component includes. There are three SACM roles: provider, 699 consumer, and controller. The roles associated with a SACM 700 component are determined by the purpose of the SACM functions and 701 corresponding SACM interfaces the SACM component is composed of. 703 Security Automation: The process of which security alerts can be 704 automated through the use of different tools to monitor, evaluate 705 and analyze endpoint and network traffic for the purposes of 706 detecting misconfigurations, misbehaviors or threats. 708 Software Package: A generic software package (e.g. a text editor). 710 Software Component: A software package installed on an endpoint, 711 including a unique serial number if present (e.g. a text editor 712 associated with a unique license key). 714 Software Instance: A running instance of the software component 715 (e.g. on a multi-user system, one logged-in user has one instance 716 of a text editor running and another logged-in user has another 717 instance of the same text editor running, or on a single-user 718 system, a user could have multiple independent instances of the 719 same text editor running). 721 State: A volatile subset endpoint attributes of a (target) endpoint 722 that is affected by a reboot-cycle. Local state is created by the 723 interaction of components with other components via the control 724 plane, via processing data plane payload, or via the functional 725 properties of local hardware and software components. Dynamic 726 configuration (e.g. IP address distributed dynamically via an 727 address distribution and management services, such as DHCP) is 728 considered state that is the result of the interaction with 729 another component that provides configuration via the control 730 plane (e.g. provided by a DHCP server with a specific 731 configuration). 733 Exmaples: The static association of an IP address and a MAC 734 address in a DHCP server configuration, a directory-path that 735 identifies a log-file directory, a registry entry. 737 Statement: A statement is a subject defined in the SACM information 738 model. 740 When a statement is used to provide content to a SACM domain, it 741 is a top-level subject that bundles Content Elements into one 742 subject and includes metadata about the data origin. 744 Subject: A composite information element. Like Attributes, subjects 745 have a name and are composed of attributes and/or other subjects. 746 Every IE that is part of a subject can have a quantitiy associated 747 with it (e.g. zero-one, none-unbounded). The content IE of a 748 subject can be an unordered or an ordered list. 750 Supplicant: A SACM component seeking to be authenticated via the 751 control plane for the purpose of participating in a SACM domain. 753 System Resource: Defined in [RFC4949] as "data contained in an 754 information system; or a service provided by a system; or a system 755 capacity, such as processing power or communication bandwidth; or 756 an item of system equipment (i.e., hardware, firmware, software, 757 or documentation); or a facility that houses system operations and 758 equipment. 760 Target Endpoint: A target endpoint is an "endpoint under assessment" 761 (even if it is not actively under assessment at all times) or 762 "endpoint of interest". Every endpoint that is not specifically 763 designated as an excluded endpoint is a target endpoint. A target 764 endpoint is not part of a SACM domain unless it contains a SACM 765 component (e.g. a SACM component that publishes collection results 766 coming from an internal collector). 768 A target endpoint is similar to a device that is a Target of 769 Evaluation (TOE) as defined in Common Criteria. 771 Target Endpoint Characterization Record: A set of endpoint 772 attributes about a target endpoint that was encountered in a SACM 773 domain, which are associated with a target endpoint by being 774 included in the corresponding record. A characterization record 775 is intended to be a representation of an endpoint. It cannot be 776 assured that a record distinctly represents a single target 777 endpoint unless a set of one or more endpoint attributes that 778 compose a unique set of identifying endpoint attributes are 779 included in the record. Otherwise, the set of identifying 780 attributes included in a record can match more than one target 781 endpoints, which are - in consequence - indistinguishable to a 782 SACM domain until more qualifying endpoint attributes can be 783 acquired and added to the record. A characterization record is 784 maintained over time in order to assert that acquired endpoint 785 attributes are either about an endpoint that was encountered 786 before or an endpoint that has not been encountered before in a 787 SACM domain. A characterization record can include, for example, 788 acquired configuration, state or observed behavior of a specific 789 target endpoint. Multiple and even conflicting instances of this 790 information can be included in a characterization record by using 791 timestamps and/or data origins to differentiate them. The 792 endpoint attributes included in a characterization record can be 793 used to re-identify a distinct target endpoint over time. Classes 794 or profiles can be associated with a characterization record via 795 the Classification Task in order to guide collection, evaluation 796 or remediation tasks. 798 Target Endpoint Characterization Task: An ongoing task of 799 continuously adding acquired endpoint attributes to a 800 corresponding record. The TE characterization task manages the 801 representation of encountered target endpoints in the SACM domain 802 in the form of characterization records. For example, the output 803 of a target endpoint discovery task or a collection task can be 804 processed by the characterization task and added to the record. 805 The TE characterization Task also manages these representations of 806 target endpoints encountered in the SACM domain by splitting or 807 merging the corresponding records as new or more refined endpoint 808 attributes become available. 810 Input: discovered target endpoint attributes, endpoint attribute 811 collection, existing characterization records 813 Output: target endpoint characterization records 815 Target Endpoint Classification Task: The task of associating a class 816 from an extensible list of classes with an endpoint 817 characterization record. TE classes function as imperative and 818 declarative guidance for collection, evaluation, remediation and 819 security posture assessment in general. 821 Input: endpoint characterization records (without classification), 822 guidance (how to classify a record) 824 Output: endpoint characterization records (with classification) 826 Target Endpoint Discovery Task: The ongoing task of detecting 827 previously unknown interaction of a potential target endpoint in 828 the SACM domain. TE Discovery is not directly targeted at a 829 specific target endpoint and therefore an un-targeted task. SACM 830 Components conducting the discovery task as a part of their 831 function are typically distributed and located, for example, on 832 infrastructure components or collect from those remotely via 833 appropriate interfaces. Examples of infrastructure components 834 that are of interest to the discovery task include routers, 835 switches, VM hosting or VM managing components, AAA servers, or 836 servers handling dynamic address distribution. 838 Input: endpoint attributes acquired via local or remote interfaces 840 Output: endpoint attributes including metadata such as data source 841 or data origin 843 Target Endpoint Identifier: The target endpoint discovery task and 844 the collection tasks can result in a set of identifying endpoint 845 attributes added to a corresponding Characterization Record. This 846 subset of the endpoint attributes included in the record is used 847 as a target endpoint identifier, by which a specific target 848 endpoint can be referenced. Depending on the available 849 identifying attributes, this reference can be ambiguous and is a 850 "best-effort" mechanism. Every distinct set of identifying 851 endpoint attributes can be associated with a target endpoint label 852 that is unique in a SACM domain. 854 Target Endpoint Label: A specific endpoint label that refers to a 855 target endpoint identifier used to identify a specific target 856 endpoint (also referred to as TE label). In content-metadata, 857 this label is called data source. 859 Target Endpoint Profile: A bundle of expected or desired 860 configurations and states (typically a composition of endpoint 861 attribute value pairs) that can be associated with a target 862 endpoint. The corresponding task by which the association with a 863 target endpoint takes places is the endpoint classification. The 864 task by which an endpoint profile is created is the endpoint 865 characterization. A type or class of target endpoints is defined 866 within a target endpoint profile, e.g. printer, smartphone, or an 867 office PC. 869 SACM Task: A SACM task is conducted by one or more SACM functions 870 that reside on a SACM component (e.g. a collection task or 871 endpoint characterization). A SACM task can be triggered by other 872 operations or functions (e.g. a query from another SACM component 873 or an unsolicited push on the data plane due to an ongoing 874 subscription). A task is part of a SACM process chain. A task 875 starts at a given point in time and ends in a deterministic state. 876 With the exception of a collection task, a SACM task consumes SACM 877 statements provided by other SACM components. The output of a 878 task is a result that can be provided (e.g. published) on the data 879 plane. There following tasks are defined by SACM: 881 Target Endpoint Discovery 883 Target Endpoint Characterization 885 Target Endpoint Classification 887 Collection 889 Evaluation [TBD] 891 Information Sharing [TBD] 893 SACM Component Discovery 895 SACM Component Authentication [TBD] 897 SACM Component Authorization [TBD] 899 SACM Component Registration [TBD] 901 Timestamps : Defined in [RFC4949] as "with respect to a data object, 902 a label or marking in which is recorded the time (time of day or 903 other instant of elapsed time) at which the label or marking was 904 affixed to the data object" and as "with respect to a recorded 905 network event, a data field in which is recorded the time (time of 906 day or other instant of elapsed time) at which the event took 907 place.". 909 This term is used in SACM to describe a recorded point in time at 910 which, for example, an endpoint attribute is created or updated by 911 a target endpoint and observed, transmitted or processed by a SACM 912 component. Timestamps can be created by target endpoints or SACM 913 components and are associated with endpoint attributes provided or 914 consumed by SACM components. Outside of the domain of SACM 915 components the assurance of correctness of time stamps is 916 typically significantly lower than inside a SACM domain. In 917 general, it cannot be simply assumed that the source of time a 918 target endpoint uses is synchronized or trustworthy. 920 Vulnerability Assessment: The process of determining whether a set 921 of endpoints is vulnerable according to the information contained 922 in the vulnerability description information. 924 Vulnerability Description Information: Information pertaining to the 925 existence of a flaw or flaws in software, hardware, and/or 926 firmware, which could potentially have an adverse impact on 927 enterprise IT functionality and/or security. Vulnerability 928 description information should contain enough information to 929 support vulnerability detection. 931 Vulnerability Detection Data: A type of imperative guidance 932 extracted or derived from vulnerability description information 933 that describes the specific mechanisms of vulnerability detection 934 that is used by an enterprise's vulnerability management 935 capabilities to determine if a vulnerability is present on an 936 endpoint. 938 Vulnerability Management Capabilities: An enterprise IT department's 939 ability to manage endpoint vulnerabilities and associated metadata 940 on an ongoing basis by ingesting vulnerability description 941 information and vulnerability detection data, and performing 942 vulnerability assessments. 944 Vulnerability assessment capabilities: An enterprise IT department's 945 ability to determine whether a set of endpoints is vulnerable 946 according to the information contained in the vulnerability 947 description information. 949 Workflow: 951 A workflow is a modular composiion of tasks. A workflow can contain 952 loops, conditionals, multiple starting points and multiple endpoints. 953 The most promiminant workflow in SACM is the assessment workflow. 955 3. IANA Considerations 957 This memo includes no request to IANA. 959 4. Security Considerations 961 This memo documents terminology for security automation. While it is 962 about security, it does not affect security. 964 5. Acknowledgements 966 6. Change Log 968 Changes from version 00 to version 01: 970 o Added simple list of terms extracted from UC draft -05. It is 971 expected that comments will be received on this list of terms as 972 to whether they should be kept in this document. Those that are 973 kept will be appropriately defined or cited. 975 Changes from version 01 to version 02: 977 o Added Vulnerability, Vulnerability Management, xposure, 978 Misconfiguration, and Software flaw. 980 Changes from version 02 to version 03: 982 o Removed Section 2.1. Cleaned up some editing nits; broke terms 983 into 2 sections (predefined and newly defined terms). Added some 984 of the relevant terms per the proposed list discussed in the IETF 985 89 meeting. 987 Changes from version 03 to version 04: 989 o TODO 991 Changes from version 04 to version 05: 993 o TODO 995 Changes from version 05 to version 06: 997 o Updated author information. 999 o Combined "Pre-defined Terms" with "New Terms and Definitions". 1001 o Removed "Requirements language". 1003 o Removed unused reference to use case draft; resulted in removal of 1004 normative references. 1006 o Removed introductory text from Section 1 indicating that this 1007 document is intended to be temporary. 1009 o Added placeholders for missing change log entries. 1011 Changes from version 06 to version 07: 1013 o Added Contributors section. 1015 o Updated author list. 1017 o Changed title from "Terminology for Security Assessment" to 1018 "Secure Automation and Continuous Monitoring (SACM) Terminology". 1020 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 1022 o Added appendix The Attic to stash terms for future updates. 1024 o Added Authentication, Authorization, Data Confidentiality, Data 1025 Integrity, Data Origin, Data Provenance, SACM Component, SACM 1026 Component Discovery, Target Endpoint Discovery. 1028 o Major updates to Building Block, Function, SACM Role, Target 1029 Endpoint. 1031 o Minor updates to Broker, Capability, Collection Task, Evaluation 1032 Task, Posture. 1034 o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, 1035 Endpoint Discovery to Endpoint Identification. 1037 o Moved Asset Targeting, Client, Endpoint Identification to The 1038 Attic. 1040 o Endpoint Attributes added as a TODO. 1042 o Changed the structure of the Change Log. 1044 Changes from version 07 to version 08: 1046 o Added Assertion, Collection Result, Collector, Excluded Endpoint, 1047 Internal Collector, Network Address, Network Interface, SACM 1048 Domain, Statement, Target Endpoint Identifier, Target Endpoint 1049 Label, Timestamp. 1051 o Major updates to Attributes, Broker, Collection Task, Consumer, 1052 Controller, Control Plane, Endpoint Attributes, Expected Endpoint 1053 State, SACM Function, Provider, Proxy, Repository, SACM Role, 1054 Target Endpoint. 1056 o Minor updates to Asset, Building Block, Data Origin, Data Source, 1057 Data Provenance, Endpoint, Management Plane, Posture, Posture 1058 Attribute, SACM Component, SACM Component Discovery, Target 1059 Endpoint Discovery. 1061 o Relabeled Function to SACM Function. 1063 Changes from version 08 to version 09: 1065 o Updated author list. 1067 o Added Data Plane, Endpoint Characterization, Endpoint 1068 Classification, Guidance, Interaction Model, Software Component, 1069 Software Instance, Software Package, Statement, Target Endpoint 1070 Profile, SACM Task. 1072 o Removed Building Block. 1074 o Major updates to Control Plane, Endpoint Attribute, Expected 1075 Endpoint State, Information Model, Management Plane. 1077 o Minor updates to Attribute, Capabilities, SACM Function, SACM 1078 Component, Collection Task. 1080 o Moved Asset Characterization to The Attic. 1082 Changes from version 09 to version 10: 1084 o Added Configuration Drift, Data in Motion, Data at Rest, Endpoint 1085 Management Capability, Hardware Component, Hardware Inventory, 1086 Hardware Type, SACM Interface, Target Endpoint Characterization 1087 Record, Target Endpoint Characterization Task, Target Endpoint 1088 Classification Task, Target Endpoint Discovery Task, Vulnerability 1089 Description Information, Vulnerability Detection Data, 1090 Vulnerability Management Capability, Vulnerability Assessment 1092 o Added references to i2nsf definitions in Capability, SACM 1093 Component, SACM Interface, SACM Role. 1095 o Added i2nsf Terminology I-D Reference. 1097 o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier. 1099 o Minor Updates to Guidance, SACM Component Discovery, Target 1100 Endpoint Label, Target Endpoint Profile. 1102 o Relabeled SACM Task 1104 o Removed Target Endpoint Discovery 1106 Changes from version 10 to version 11: 1108 o Added Content Element, Content Metadata, Endpoint Label, 1109 Information Element, Metadata, SACM Component Label, Workflow. 1111 o Major Updates to Assessment, Capability, Collector, Endpoint 1112 Management Capabilities, Guidance, Vulnerability Assessment 1113 Capabilities, Vulnerability Detection Data, Vulnerability 1114 Assessment Capabilities. 1116 o Minor updates to Collection Result, Control Plane, Data in Motion, 1117 Data at Rest, Data Origin, Network Interface, Statement, Target 1118 Endpoint Label. 1120 o Relabeled Endpoint Management Capability, Vulnerability Management 1121 Capability, Vulnerability Assessment. 1123 Changes from verion 11 to version 12: 1125 o Added Configuration, Endpoint Characteristic, Event, SACM Content, 1126 State, Subject. 1128 o Major Updates to Asserition, Data in Motion, Data Provenance, Data 1129 Source, Interaction Model. 1131 o Minor Updates to Attribute, Control Plane, Data Origin, Data 1132 Provenance, Expected Endpoint State, Guidance, Target Endpoint 1133 Classification Task, Vulnerability Detection Data. 1135 7. Contributors 1136 David Waltermire 1137 National Institute of Standards and Technology 1138 100 Bureau Drive 1139 Gaithersburg, MD 20877 1140 USA 1142 Email: david.waltermire@nist.gov 1144 Adam W. Montville 1145 Center for Internet Security 1146 31 Tech Valley Drive 1147 East Greenbush, NY 12061 1148 USA 1150 Email: adam.w.montville@gmail.com 1152 David Harrington 1153 Effective Software 1154 50 Harding Rd 1155 Portsmouth, NH 03801 1156 USA 1158 Email: ietfdbh@comcast.net 1160 Brian Ford 1161 Lancope 1162 3650 Brookside Parkway, Suite 500 1163 Alpharetta, GA 30022 1164 USA 1166 Email: bford@lancope.com 1168 Merike Kaeo 1169 Double Shot Security 1170 3518 Fremont Avenue North, Suite 363 1171 Seattle, WA 98103 1172 USA 1174 Email: merike@doubleshotsecurity.com 1176 8. Informative References 1178 [I-D.ietf-i2nsf-terminology] 1179 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1180 Birkholz, "Interface to Network Security Functions (I2NSF) 1181 Terminology", draft-ietf-i2nsf-terminology-03 (work in 1182 progress), March 2017. 1184 [I-D.ietf-sacm-vuln-scenario] 1185 Coffin, C., Cheikes, B., Schmidt, C., Haynes, D., 1186 Fitzgerald-McKay, J., and D. Waltermire, "SACM 1187 Vulnerability Assessment Scenario", draft-ietf-sacm-vuln- 1188 scenario-02 (work in progress), September 2016. 1190 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1191 Information Models and Data Models", RFC 3444, 1192 DOI 10.17487/RFC3444, January 2003, 1193 . 1195 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1196 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1197 . 1199 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1200 Tardo, "Network Endpoint Assessment (NEA): Overview and 1201 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1202 . 1204 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1205 (PA) Protocol Compatible with Trusted Network Connect 1206 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1207 . 1209 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1210 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1211 March 2011, . 1213 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 1215 Appendix A. The Attic 1217 The following terms are stashed for now and will be updated later: 1219 Asset Characterization: Asset characterization is the process of 1220 defining attributes that describe properties of an identified 1221 asset. 1223 Asset Targeting: Asset targeting is the use of asset identification 1224 and categorization information to drive human-directed, automated 1225 decision making for data collection and analysis in support of 1226 endpoint posture assessment. 1228 Client: An architectural component receiving services from another 1229 architectural component. 1231 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 1232 The process by which an endpoint can be identified. 1234 Authors' Addresses 1236 Henk Birkholz 1237 Fraunhofer SIT 1238 Rheinstrasse 75 1239 Darmstadt 64295 1240 Germany 1242 Email: henk.birkholz@sit.fraunhofer.de 1244 Jarrett Lu 1245 Oracle Corporation 1246 4180 Network Circle 1247 Santa Clara, CA 95054 1248 USA 1250 Email: jarrett.lu@oracle.com 1252 John Strassner 1253 Huawei Technologies 1254 2330 Central Expressway 1255 Santa Clara, CA 95138 1256 USA 1258 Email: john.sc.strassner@huawei.com 1260 Nancy Cam-Winget 1261 Cisco Systems 1262 3550 Cisco Way 1263 San Jose, CA 95134 1264 USA 1266 Email: ncamwing@cisco.com