idnits 2.17.1 draft-schaad-sacm-architecture-00.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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-----------' is mentioned on line 396, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-sacm-requirements-14 -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Informational D. Waltermire 5 Expires: May 4, 2017 National Institute of Standards and Technology 6 October 31, 2016 8 Prospective Architecture for SACM 9 draft-schaad-sacm-architecture-00 11 Abstract 13 This document describes the high level architecture for Security 14 Automation and Continuous Monitoring (SACM). The architecture 15 identifies the components that provide for the collection, storage, 16 dissemination, and evaluation of posture information. This 17 architecture also describes the interfaces and associated operations 18 that define the interactions between these components. This 19 information will inform future engineering work around identifying 20 existing standards for collecting, storing, disseminating, and 21 evaluating endpoint posture information. This architecture will also 22 help in identifying standardization gaps that require new engineering 23 effort. 25 Security practitioners need to request, analyze, and aggregate 26 posture information from disparate sources that use differing means 27 to identify endpoints, hardware, software, and configurations. This 28 task is made harder by the large number of different protocols and 29 formats needed to bring together all of this information into a 30 single view. This architecture provides a means to automatically 31 gather posture data together for standardized dissemination to 32 downstream components. This allows security practitioners that 33 leverage this architecture to focus on managing security problems, 34 not data. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 4, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. SACM Components . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Combining Roles . . . . . . . . . . . . . . . . . . . . . 7 73 2.2. SACM Collection . . . . . . . . . . . . . . . . . . . . . 8 74 2.2.1. Use of Existing Management Protocols . . . . . . . . 10 75 2.2.2. The Need for Collection Choreography . . . . . . . . 10 76 2.2.3. Collected Information Dissemination . . . . . . . . . 12 77 3. SACM Protocols . . . . . . . . . . . . . . . . . . . . . . . 12 78 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 14 79 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 8. Informational References . . . . . . . . . . . . . . . . . . 15 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 This document represents some views of the authors but should not be 89 considered to be the opinions of them either individually or 90 collectively. The document is designed both to clarify the thinking 91 of the authors as well as to create some discussion on what the 92 architecture looks like. As such, it is entirely reasonable that 93 section of the document (i.e. the one on the IM) should be combined, 94 removed or replaced. This can be either because they do not belong 95 in this document or because they are just wrong. 97 Another aim of the document is to clarify what pieces of the work may 98 need to be done in the future as this may help clarify some of the 99 dicussions are underway or have been completed. This is the aim of 100 the list of protocols associated with a component. With this, we can 101 perhaps start looking at what DM(s) are doing when they are sending 102 data. 104 Jim: Part of the questions that would need to be addressed before 105 publication is the audience of the document. It is my personal 106 feeling that the document should be sufficently complete that it can 107 be handed to a person who is not in the community, and they should be 108 able to understand all of the pieces and how they interact. 110 To manage information system security risk, network operators must 111 know the operational state of the endpoints they manage, and must be 112 able to assess known vulnerabilities against this operational state 113 to understand potential security risks. This helps the network 114 operator to determine which threats a given endpoint might be subject 115 to, and supports decision making around actions that mitigate the 116 associated risk. Vulnerability assessment is an example of this type 117 of analysis, where endpoint software inventory is compared with known 118 vulnerable software versions reported by software vendors and 119 vulnerability researchers to determine which endpoints have 120 vulnerable software. Knowledge of vulnerable software on endpoints 121 can then drive software patching activities, reducing the attack 122 surface of the network. Additionally, many organizations develop 123 compliance requirements based on their understanding of security 124 risks. These compliance requirements, also called policies, define 125 what software may be installed on a given endpoint and how that 126 software must be configured to achieve a sufficient level of security 127 risk reduction for the organization. In both cases, an organization 128 needs to have an up-to-date view of the operational state of the 129 endpoints connected to their networks and accessing their information 130 systems. 132 Understanding the operational state of an endpoint (hereafter 133 referred to as "endpoint posture") requires the ability to collect 134 and evaluate endpoint posture information as posture changes occur. 135 In order to make decisions quickly to prevent, deflect, or mitigate 136 an attack, network operators must be able to collect, disseminate, 137 and evaluate posture information within narrow timeframes. Making 138 decisions quickly relies on automating posture collection and 139 evaluation processes so that network operators can identify 140 endpoints, software, and software configurations in a meaningful and 141 enduring way that is suitable for trending and longer-term analysis. 142 This document describes a suitable architecture that supports 143 automated collection, storage, dissemination, and evaluation of 144 endpoint posture information. 146 Still needs text dealing with other uses. 148 There is an IM and a DM. Some differences between these are found in 149 [RFC3444]. 151 2. SACM Components 153 The SACM architecture is made up of a number of different entities 154 each of which supports one or more roles. A picture of what roles 155 can exist can be found in Figure 1. 157 ----!----1----!----2----!----3----!----4----!----5----!----6----!- 159 +-----------+ +---------------+ +------------+ +-------+ 160 | Raw | | | | | | | 161 | Data | | Authenticator | | Authorizor | | Data | 162 | Collector | | | | | | Store | 163 +-----------+ +---------------+ +------------+ +-------+ 164 | | | / 165 +-----------+ +-----------+ 166 | SACM |- /------\ -| Directory | 167 | Collector | / SACM \ +-----------+ 168 +-----------+ / \ 169 | | +-------------+ 170 +--------+ \ CLOUD / -| Aggregators | 171 | SACM |----- \ / +-------------+ 172 | Proxy | \------/ 173 +--------+ +------------+ 174 | | | | Evaluators | 175 /-----------\ +------------+ +-----------+ +------------+ 176 | External | | Policy | | External | 177 | SACM | | Management | | Event | 178 | Cloud | +------------+ | Processor | 179 \-----------/ +-----------+ 181 Figure 1: SACM Architecture 183 A description of the different roles in the picture above is as 184 follows: 186 Authenticator: is a role that provides authentication services for 187 other entities within the architecture. Entities can interact 188 with an authenticator once and be provided with a long term 189 credential, such as a certificate, or can be interacted with 190 whenever authentiction is needed, such as an EAP server. Even 191 when interacting on a frequent basis, a short term credential such 192 as a SAML assertion can be provided. Interactions with an 193 authenticator include: 195 * Enrollment: The act of being introduced to the authentication 196 system. 198 * Revocation: The act of being removed from the authentication 199 system. 201 * Authentication: The act of proving an identity to the 202 authentication system matches one that was introduced to it. 204 Authorizer: is a role that provides authorization and access control 205 to data and capabilities for an entity within the architecture. 206 Frequently, but not always authorizers and authenticators will be 207 co-located and administered. Interactions with an authorizer 208 include: 210 * Authorization: An administrative act of adding authorizations 211 for an identity. 213 * Revocation: An administrative act of removing authorizations 214 for an identity. 216 * Querying: The act of asking if an identity is authorized for 217 performing an action or receiving data. 219 Directory: is a role that provides methods to locate where services 220 and data can be found in the architecture. Interactions with a 221 directory include: 223 * Publishing: The act of telling a directory what services or 224 data can an entity provides. 226 * Unpublishing: The act of removing from a directory a list of 227 services or data that an entity provides. 229 * Querying: The act of asking a directory where a service or set 230 of data can be found. 232 * Directory Location: The act of finding a directory in the first 233 place. 235 Data Store: is a role that provides a repository for data to be 236 published into and queried from. Interactions with a data store 237 include: 239 * Publishing: The act of providing data to a data store. 241 * Querying: The act of obtaining data from a data store. 243 * Synchronization: The act of two data stores making the data 244 they hold consistent. 246 SACM Collector: is a role that obtains data and then publishes it 247 into the SACM environment. A SACM collect will either publish the 248 data to a data store, or act as a data store itself. SACM 249 collectors can location and publish data either in response to a 250 query, if they act as a data store, on a schedule, or in response 251 to some event. A SACM collector will format data provided to it 252 into the SACM Information model, decorating it as necessary, and 253 then provide it to the rest of the environment. 255 Raw Data Collector: is a role that is ancillary to the SACM 256 architecture rather than being a core component. Raw data 257 collectors gather data which is fed to a SACM collector. Examples 258 of raw data collectors could be NEA components, asset management 259 databases (hardware, software or wetware), or network state 260 databases such as a DHCP server. 262 Aggregator: is a role that looks at data in the SACM environment, 263 combines together pieces of related data and publishes the new 264 relationships back into the environment. An example of what an 265 aggregator might do is to look at the information provided by a 266 DHCP server along with historic IP address information for a 267 machine to determine when records referring to a machine are the 268 same one or different ones. 270 Evaluator: is a role that looks a the data in the SACM environment 271 along with a set of evaluation criteria, compares the data with 272 the criteria and publishes the results of the evaluation back into 273 the environment. Evaluators can look at things as simple as are 274 all of the pieces of software on a machine licensed to as 275 complicated as comparing data for a network or machine against an 276 intrusion report. 278 SACM Proxy: is a role that allows for data to be transfered between 279 two different SACM environments. SACM proxies frequently provide 280 the data store role as well so that they can know what data needs 281 to be synchronized between the two subsystems. SACM proxies can 282 exist in environments where they are always active, or where only 283 intermittent connectivity exists between the two subsystems. 285 Policy Management: is a role that controls different policy 286 configurations for the environment. This includes such things as: 287 What to report and who to report it to. Conditions under which 288 automated remediation should automatically be applied. What the 289 priorities are used in performing evaluations and frequencies of 290 evaluations. 292 External Event: is a role that acts between the SACM environment and 293 external non-SACM systems. One type of interaction that would be 294 covered here is dealing with external vulnerability reports. As 295 reports come from external sources, they need to be messaged into 296 the correct format for storage in the SACM IM and then supplied to 297 evaluators to identify if the vulnerability exists in systems SACM 298 monitors. The same thing can happen in reverse, where 299 vulnerabilities or conditions that look like they might be 300 vulnerabilities could be reported to an external centeralized 301 authority. 303 In many cases it is not always clear where a single service falls. A 304 simple example of this is where the NEA protocol would fit into the 305 picture. NEA can be treated either as an internal collector or as an 306 external collector depending on what is being collected and how the 307 observer feels about the world. Many of the core things that NEA 308 collects today are not directly mapped to the SACM Information Model 309 without some massaging, as such it is reasonable to look at this as 310 being an external collector with the NEA server being co-resident 311 with the SACM External Collector. This entity would take the NEA 312 data, convert it into the SACM IM, and then publish it using one of 313 the SACM DMs. On the other hand, it is also possible that NEA would 314 collect data that corresponds directly to a SACM IM and return the 315 data already encoded in a SACM DM. In this case, it would make sense 316 to consider the NEA client as being a SACM Internal collector which 317 publishes using NEA as the publishing protocol and the ENA server 318 being either a proxy or a data store. 320 2.1. Combining Roles 322 In many cases more than one role will be combined into a single 323 entity. In this section a view of how roles might be combined 324 together to provide support as a proxy for the Ice Station Zebra use 325 case in [RFC7632]. In this scenario, the enterprise has two 326 different SACM sub-systems. One sub-system is at the main enterprise 327 and the other sub-system is at Zebra. There is not a constant high- 328 speed connection between the two sub-systems, instead data is 329 exchanged an intermittent, low-speed, high-latency link. 331 The proxy role is the one that sits between the two subsystems, that 332 is what it is designed for. Due to the link, one would have two 333 different proxies one on either side of the link. The entity that 334 contains the proxy may additionally have the following roles: 336 o Data Store: Placing a data store on the proxy allows for queries 337 about devices on the other size to be queued up and synchronized 338 across the connection. Additionally, having a data store for 339 those items on the opposite side of the link allows that data 340 store to specialize on how to optimally synchronize data across 341 the link. 343 o Directory Service: Placing a directory service that tells about 344 the systems and services on opposite side of the connection allows 345 for the ability to filter down the set of registrations that are 346 passed over the link. 348 o Authorization Service: The authorizations may be changed for some 349 entities based on the location of the service they are asking 350 about. A user may have basically unlimited authorization for the 351 local subsystem, but may have limited authorization for the remove 352 subsystem. This rule would apply whether they were at the home 353 base or at Zebra. 355 2.2. SACM Collection 357 The collection of data in the SACM world is one of the major issues 358 that needs to be dealt with. For this reason we drill down into that 359 problem here. 361 When dealing with just the issue of collcition, the SACM architecture 362 can be thought of as having a left-hand side and a right-hand side, 363 illustrated by the dotted line in Figure 2. The left-hand side 364 describes how management protocols can be used to allow a Collection 365 Controller (CC) to choreograph the collection of endpoint posture 366 from a set of target endpoints through posture change subscriptions 367 or direct requests, and for endpoints to report posture information 368 based on these collection requests. The left-hand side of the 369 architecture is built upon existing endpoint management protocols; 370 however, new protocols are needed to separate out the evaluation and 371 collection capabilities defined by some of these protocols (e.g., 372 NEA). 374 | 375 +----------+ | 376 | | | +-----------+ 377 | Target +---------+ | +---------------------------> | 378 | Endpoint | | | | | Datastore | 379 | | | | | +------------> | 380 +----------+ +v---------v-+ | | | 381 | | {-------v---} +-----^-----+ 382 +----------+ | | { } | 383 | | | Collection | { Messaging } | 384 | Target <--------> Controller <--> Protocol +--------+ | 385 | Endpoint | | | { | | | 386 | | | | { | Broker | | 387 +----------+ | | {--^-----+ | | 388 +^---------^-+ | +--------+ | 389 +----------+ | | | | +-----v-----+ 390 | | | | | +-----------------> | 391 | Target <---------+ | | | Evaluator | 392 | Endpoint | | +---------------------------> | 393 | | | | | 394 +----------+ | +-----------+ 395 | 396 [-----------] | 397 Management | 398 Protocol | 399 Interfaces | 400 | 401 Left-Hand Side | Right-Hand Side 403 Figure 2: SACM Architecture 405 At the center of the SACM architecture is a CC that spans the left- 406 and right-hand sides. The CC choreographs the collection of posture 407 information on the left-hand side, and provides a common view of the 408 collected posture for the right-hand side. Working in this way, all 409 Evaluators that consume posture information from a given CC are 410 provided a common view of all endpoint posture information collected 411 by the CC. This common view can be accessed by Evaluators who need 412 this information for asset management, configuration management, and 413 vulnerability management use cases, and collected posture information 414 can also be made available to other posture consumers to support 415 unforeseen use cases. 417 The right-hand side of the SACM architecture defines how posture 418 information is shared between components that provide collected 419 posture (e.g., a Collection Controller) and components that store, 420 evaluate, and use collected posture information on the network. 421 Analytical and reporting capabilities need to be able to publish and 422 subscribe to posture data feeds from other tools that have the 423 required information. Other capabilities may need to access data 424 stores of previously collected, historic posture information. By 425 separating the methods of posture collection from how this 426 information is consumed for use, the SACM architecture protects 427 endpoints from being overloaded by downstream requests, and posture 428 data from unauthorized access. These benefits support security 429 automation by providing improved access to posture information by 430 downstream consumers, and allowing downstream components to 431 communicate information derived from posture analysis. 433 The following subsection discuss the motivations for the SACM 434 architecture. 436 2.2.1. Use of Existing Management Protocols 438 On the left-hand side of the SACM architecture, a number of existing, 439 widely deployed endpoint management protocols support the collection 440 of posture information from endpoints. Examples of these protocols 441 include: the Simple Network Management Protocol (SNMP) [RFC3411], 442 Network Configuration Protocol (NETCONF) [RFC4741], and the Network 443 Endpoint Assessment (NEA) protocol [RFC5209]. These and similar 444 protocols provide extension points that allow for new types of 445 posture information to be represented and collected over time. For 446 these reasons, integration with existing posture collection protocols 447 is a key feature of this architecture. 449 A gap in the functionality provided by existing protocols is a 450 generalized mechanism to allow external components to drive data 451 collection activities through a common, protocol agnostic collection 452 interface. This is a feature supported by the SACM architecture 453 through the definition of a common interface on the right-hand side 454 that allows the CC to choreograph posture collection through 455 implementations of existing management protocols on the left-hand 456 side. 458 2.2.2. The Need for Collection Choreography 460 Collection choreography is the act of managing posture collection 461 activities on the left-hand side to produce a common view of 462 collected posture information for one or more collection consumers on 463 the right-hand side. Collection choreography is supported in the 464 SACM architecture by the Collection Controller (CC) for the following 465 reasons: 467 Simplification of Collection Clients Multiple management protocols 468 are needed to fullfil posture information collection requests 469 across different types of endpoints. To provide coverage of 470 all posture information that may need to be collected, any 471 component driving posture collection must be well versed in 472 multiple protocols and associated data models. Developing and 473 maintaining this level of protocol support is a heavy burden to 474 place on Evaluators. Additionally, some management solutions 475 make use of specialized collection managers or proxies (e.g., 476 mobile device management) that directly communicate with the 477 target endpoint(s) on behalf of requesting clients. Requiring 478 evaluators to locate and communicate with these proxies would 479 discourage development and adoption of SACM solutions. The 480 SACM architecture reduces the implementation burden on 481 Evaluators by making the CC manage which collection services a 482 request should be sent to when satisfying a given SACM 483 collection request. This allows Evaluators to focus only on 484 identifying and processing the data they request, and not on 485 managing the collection process. 487 Authenticating, Authorizing, and Controlling Access of Data 488 Collection Consumers 489 An automated collection system can pose a significant risk 490 to an organization if the system can be misused by an 491 attacker to gain knowledge of the operational state of 492 endpoints. Once accessed by an attacker, this information 493 can be used to attack other hosts or move laterally within a 494 network. For this reason, access to collected endpoint 495 posture information must be restricted to authenticated and 496 authorized entities. Different management protocols may 497 employ different authentication and authorization schemes. 498 Through the use of a shared CC, access can be controlled in 499 a way that unifies the underlying authentication, 500 authorization, and access control schemes. 502 Reducing Performance Impacts on the Target Endpoint Without a 503 common CC, Evaluators would need to directly interact with 504 an endpoint to request posture data. Multiple clients 505 operating in this way might request the same posture data 506 within a narrow time window, resulting in multiple 507 collection operations that can reduce the operational 508 performance of the endpoint. Use of a CC can allow these 509 repetitive and duplicative collection operations to be 510 optimized. Working in this way, the CC can compute an 511 optimal collection approach, using the appropriate 512 management protocols to efficiently collect any needed 513 posture data. This data can be cached by the CC, operating 514 as a Data Store, and can be reused within an appropriate 515 time window to provide multiple clients with the same 516 collected posture information. 518 For these reasons a Collection Controller is needed to choreograph 519 posture collection within the SACM architecture. 521 2.2.3. Collected Information Dissemination 523 On the right-hand side of the SACM architecture, once collection has 524 been triggered and choreographed, there remains the issue of 525 efficiently disseminating the collected posture information to 526 consumers. The collection activity will have yielded information in 527 an arbitrary data format, often spread across several formats with 528 overlapping and mismatched information. There is a need for a means 529 to package this information in a standardized way such that automated 530 systems downstream can consume it without a priori knowledge of the 531 source format. 533 The SACM architecture needs to support direct request response and 534 publish subscribe mechanisms for posture data dissemination. In 535 either case, arbitrary data formats can be processed at collection 536 time and re-enveloped by a standardized information description. The 537 downstream consumer needs to only understand the enveloping model to 538 process the message containing posture information. It might also be 539 possible to allow the enveloping model to identify multiple formats, 540 allowing the consumer to request information from the designated 541 source in a specific format it recognizes and supports. 543 3. SACM Protocols 545 List of protocols: 547 Authentication: A method of doing an entity to authenticate itself 548 is required. Several potential candidates exist for this purpose. 549 Among these candidates are X.509 certificates, SAML assertions, 550 EAP or GSS-API. 552 Authorization: A standardized method of either querying the 553 authorization server or carrying authorization information needs 554 to be selected. Some of the candidates for this would be SAML 555 assertions or X.509 attribute certificates. 557 Query: There will exist a standardized method for querying data from 558 a repository. The query protocal needs to do the following 559 things: 561 Get the required authentication for the quester. The server 562 needs to authenticate both that the requester has the needed 563 rights both to make the query and to have access to the data 564 involved. 566 The entities need to negotiate a data model to be used for the 567 creation of the query and to express the query in. 569 The entities need to negotiate a data model, a serialization 570 abstraction and a serialization data format for data to be 571 returned in response to a query. 573 The ability to specify required meta-data as part of the query 574 is a requirement. As an example, the ability to require that 575 the data be collected after a given date and time is required. 577 The ability to negotiate the frequency that the data is to be 578 returned to the client. Data may be required as a one time 579 event or as an ongoing event. One time events may be returned 580 either immediately, or when the query can be completed as the 581 data becomes available. Ongoing responses can be based on a 582 time interval or based on some event happening. For ongoing 583 response, the criteria for specify the frequency of response 584 needs to be both negotiated and authorized. 586 Response: There will exist a standardized method for sending data 587 from a server to a client. Data may be sent to a client based 588 either on a request for data, a prior request for data or because 589 the server decided the client needs the data. Servers need to do 590 the authentication and authorization on the data to be returned at 591 a regular basis. 593 Directory Register: There will exist a standardized method for 594 registering and unregistering data in a directory service. 596 Directory Query: There will exist a standardized method for querying 597 the directory service for supported services. 599 Publish: There will exist a standardized method for publishing data 600 into a repository. The method will: 602 * Verify the identity and authorization of the publisher. 604 * If needed, negotiate the format in which the data is presented. 605 This includes the data model, data abstraction and data 606 serialization. 608 * Verify that the required meta-data that the publisher must 609 provide is present. 611 * Provide repository based meta-data. 613 Additionally, the repository will potentially trigger events 614 within the server for dealing with outstanding requests for data 615 or evaluations. 617 Synchronization: There will exist a standardized method for doing 618 synchronization between multiple data stores. This method will: 620 * TBD. 622 Collection: Many different protocols can be used to do collection 623 over. One of these is NEA [RFC5209] which acts as a transport for 624 serializations of SACM data models. The use of NEA as the 625 transport satisifes the following requirements: 627 * NEA requires the use of TLS [TLS??] for cryptographic 628 protection between the client and the server. 630 * NEA has defined two authentication protocols to run between the 631 client and the server. These are PT-TLS [RFC6876] and PT-EAP 632 [RFC7171]. PT-TLS uses X.509 certificates on both the client 633 and server side to authenticate each side. PT-EAP allows for 634 EAP [RFC3748] to be used which allows for lighter weight 635 registration and authentication to occur. 637 * Authorization is currently of the all or none variety. 638 Authorization is done at configuration time. 640 * Discovery is not currently supported by NEA, so the server 641 location is configured onto the client. 643 [I-D.coffin-sacm-nea-swid-patnc] represents one set of attributes 644 to carry SACM information. 646 4. Information Model 648 The SACM architecture includes a single Information Model to provide 649 a consistent view of the data needed to do perform the endpoint 650 posture assessment. Additional IMs may be defined by entities other 651 than the IETF which are supersets of the IETF IM. This is one way 652 that companies will be able to differentiate their products from each 653 other. The IM includes not only the data itself, but metadata as 654 well. The meta data includes, but is not limited to: 656 o Who collected or created the data 658 o When the data was collected or created 660 o What data was used to create the data 661 o What relationships exist between different data points or 662 different versions of the same data point. 664 5. Data Model 666 The SACM architecture includes a single Data Model defined by the 667 IETF. Additional DMs maybe defined by entities other than the IETF. 668 These additional DMs may be either subsets or supersets of the IETF 669 SACM DM. The subset DMs are defined for doing special purpose work 670 which does not need the full SACM DM. 672 The term DM is used by the SACM group in two different contexts and 673 it is useful to discuss those two contexts. Data Model can refer to 674 how the data is arranged within a entity. In this view of a DM, one 675 can use a relational database as the conceptual view of the world. 676 The relations in the database reflect the relations between the data 677 in the IM. The use of a relational database is not the only way to 678 implement the DM within a process. 680 The term DM can also refer to how the data is represented when 681 serialized for transport between two entities. This is the meaning 682 that is more usual when looking at the current SACM documents. This 683 is sometimes referred to as the DM in transit. 685 6. IANA Considerations 687 This document has no IANA Considerations. 689 7. Security Considerations 691 This document is a high level description of the architecture of the 692 SACM environment, as such it does not directly specify any security 693 problems or requirements. Security requirements for SACM can be 694 found in other documents including the SACM Requirements 695 [I-D.ietf-sacm-requirements]. 697 8. Informational References 699 [I-D.ietf-sacm-requirements] 700 Cam-Winget, N. and L. Lorenzin, "Security Automation and 701 Continuous Monitoring (SACM) Requirements", draft-ietf- 702 sacm-requirements-14 (work in progress), September 2016. 704 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 705 Information Models and Data Models", RFC 3444, 706 DOI 10.17487/RFC3444, January 2003, 707 . 709 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 710 Posture Assessment: Enterprise Use Cases", RFC 7632, 711 DOI 10.17487/RFC7632, September 2015, 712 . 714 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 715 Tardo, "Network Endpoint Assessment (NEA): Overview and 716 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 717 . 719 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 720 Transport Protocol over TLS (PT-TLS)", RFC 6876, 721 DOI 10.17487/RFC6876, February 2013, 722 . 724 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 725 (PT) Protocol for Extensible Authentication Protocol (EAP) 726 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 727 . 729 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 730 Levkowetz, Ed., "Extensible Authentication Protocol 731 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 732 . 734 [I-D.coffin-sacm-nea-swid-patnc] 735 Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald- 736 McKay, "Software Inventory Message and Attributes (SWIMA) 737 for PA-TNC", draft-coffin-sacm-nea-swid-patnc-03 (work in 738 progress), October 2016. 740 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 741 Architecture for Describing Simple Network Management 742 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 743 DOI 10.17487/RFC3411, December 2002, 744 . 746 [RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, 747 DOI 10.17487/RFC4741, December 2006, 748 . 750 Acknowledgments 752 This document is currently the opinions of just the authors and is 753 not representative of the SACM working group or the IETF. 755 This document has been formed by discussions with a large number of 756 the SACM working group members including but not limited to: Henk 757 Birkholz, Lisa Lorenzin, Nancy Cam-Winget. 759 Authors' Addresses 761 Jim Schaad 762 August Cellars 764 Email: ietf@augustcellars.com 766 David Waltermire 767 National Institute of Standards and Technology 768 100 Bureau Drive 769 Gaithersburg, Maryland 20877 770 USA 772 Email: david.waltermire@nist.gov