idnits 2.17.1
draft-combined-sacm-information-model-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 :
----------------------------------------------------------------------------
** The abstract seems to contain references ([TNC]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 7, 2014) is 3516 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 3161
== Unused Reference: 'TNC-IF-M-TLV-Binding' is defined on line 1544, but no
explicit reference was found in the text
== Unused Reference: 'TNC-IF-T-TLS' is defined on line 1560, but no
explicit reference was found in the text
== Outdated reference: A later version (-16) exists of
draft-ietf-sacm-terminology-05
== Outdated reference: A later version (-10) exists of
draft-ietf-sacm-use-cases-07
== Outdated reference: A later version (-02) exists of
draft-salowey-sacm-xmpp-grid-00
-- Obsolete informational reference (is this intentional?): RFC 5201
(Obsoleted by RFC 7401)
Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force D. Waltermire, Ed.
3 Internet-Draft NIST
4 Intended status: Informational K. Watson
5 Expires: March 11, 2015 DHS
6 C. Kahn
7 L. Lorenzin
8 Juniper Networks, Inc.
9 September 7, 2014
11 SACM Information Model
12 draft-combined-sacm-information-model-00
14 Abstract
16 TODO: reconcile
18 [TNC]This document proposes an information model for endpoint posture
19 assessment. It describes the information needed to perform certain
20 assessment activities and to communicate and respond to the
21 assessments.[/TNC]
23 [wandw]This document defines an information model for aggregated
24 configuration and operational data, so that the data can be evaluated
25 to determine an organization's security posture.[/wandw]
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on March 11, 2015.
44 Copyright Notice
46 Copyright (c) 2014 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
62 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
63 2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 6
64 3. Conventions used in this document . . . . . . . . . . . . . . 7
65 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
66 4. Elements of the SACM Information Model . . . . . . . . . . . 7
67 4.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 9
68 4.1.1. Unique Endpoint Identifier . . . . . . . . . . . . . 9
69 4.1.2. Endpoint Credential . . . . . . . . . . . . . . . . . 9
70 4.1.3. Software Component . . . . . . . . . . . . . . . . . 10
71 4.1.3.1. Unique Software Identifier . . . . . . . . . . . 10
72 4.1.4. Software Instance . . . . . . . . . . . . . . . . . . 11
73 4.1.5. Hardware Component . . . . . . . . . . . . . . . . . 11
74 4.1.6. Hardware Instance . . . . . . . . . . . . . . . . . . 11
75 4.2. Internal Attribute Collector . . . . . . . . . . . . . . 11
76 4.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . 12
77 4.3.1. User Credential . . . . . . . . . . . . . . . . . . . 12
78 4.4. Network Session . . . . . . . . . . . . . . . . . . . . . 12
79 4.4.1. Address . . . . . . . . . . . . . . . . . . . . . . . 12
80 4.4.2. Authorizations . . . . . . . . . . . . . . . . . . . 12
81 4.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 13
82 4.6. External Attribute Collector . . . . . . . . . . . . . . 13
83 4.7. Endpoint Attribute Assertion . . . . . . . . . . . . . . 14
84 4.7.1. Form and Precise Meaning . . . . . . . . . . . . . . 14
85 4.7.2. Source . . . . . . . . . . . . . . . . . . . . . . . 15
86 4.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15
87 4.7.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 15
88 4.7.5. Posture Attribute . . . . . . . . . . . . . . . . . . 15
89 4.7.6. Event . . . . . . . . . . . . . . . . . . . . . . . . 16
90 4.7.7. Difference between Attribute and Event . . . . . . . 16
91 4.8. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 16
92 4.9. Evaluation Result . . . . . . . . . . . . . . . . . . . . 17
93 4.10. Report Generator . . . . . . . . . . . . . . . . . . . . 17
94 4.11. Report . . . . . . . . . . . . . . . . . . . . . . . . . 17
95 4.12. Organization? . . . . . . . . . . . . . . . . . . . . . . 18
96 4.13. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 19
97 4.13.1. Internal Collection Guidance . . . . . . . . . . . . 19
98 4.13.2. External Collection Guidance . . . . . . . . . . . . 19
99 4.13.3. Evaluation Guidance . . . . . . . . . . . . . . . . 19
100 4.13.4. Retention Guidance . . . . . . . . . . . . . . . . . 19
101 4.13.5. Reporting Guidance . . . . . . . . . . . . . . . . . 19
102 4.14. Provenance of Information . . . . . . . . . . . . . . . . 20
103 5. Graph Model . . . . . . . . . . . . . . . . . . . . . . . . . 20
104 5.1. Background: Graph Models . . . . . . . . . . . . . . . . 21
105 5.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 21
106 5.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 22
107 5.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 22
108 5.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 22
109 5.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 23
110 5.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 23
111 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24
112 6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 24
113 6.1. Graph Model for Detection of Posture Deviation . . . . . 24
114 6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 25
115 6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 25
116 6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 26
117 6.1.4. Relationships between Identifiers and Metadata . . . 26
118 6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 27
119 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
120 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
121 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
122 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
123 10.1. Normative References . . . . . . . . . . . . . . . . . . 28
124 10.2. Informative References . . . . . . . . . . . . . . . . . 29
125 Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 34
126 A.1. What is Trusted Network Connect? . . . . . . . . . . . . 34
127 A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 35
128 A.3. What is the TNC Information Model? . . . . . . . . . . . 35
129 Appendix B. Text for Possible Inclusion in the Terminology Draft 36
130 B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 36
131 B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 36
132 B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 37
133 Appendix C. Text for Possible Inclusion in the Architecture or
134 Use Cases . . . . . . . . . . . . . . . . . . . . . 37
135 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 37
136 C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 38
137 C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 39
138 Appendix D. Text for Possible Inclusion in the Requirements
139 Draft . . . . . . . . . . . . . . . . . . . . . . . 43
140 D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 43
141 D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 43
142 Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 44
143 E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 44
144 E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 44
146 E.2. From Information Needs to Information Elements . . . . . 45
147 E.3. Information Model Elements . . . . . . . . . . . . . . . 45
148 E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 47
149 E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 49
150 E.3.1.3. Software Identification . . . . . . . . . . . . . 50
151 E.3.1.4. Hardware Identification . . . . . . . . . . . . . 53
152 E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 53
153 E.3.2.1. Platform Configuration Item Identifier . . . . . 53
154 E.3.2.2. Configuration Item Identifier . . . . . . . . . . 59
155 E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 61
156 E.3.3. Endpoint characterization . . . . . . . . . . . . . . 61
157 E.3.4. Posture Attribute Expression . . . . . . . . . . . . 65
158 E.3.4.2. Platform Configuration Attributes . . . . . . . . 65
159 E.3.5. Actual Value Representation . . . . . . . . . . . . . 67
160 E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 67
161 E.3.5.2. Collected Platform Configuration Posture
162 Attributes . . . . . . . . . . . . . . . . . . . 68
163 E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 69
164 E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 69
165 E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 71
166 E.3.7.1. Configuration Evaluation Results . . . . . . . . 71
167 E.3.7.2. Software Inventory Evaluation Results . . . . . . 73
168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
170 1. Introduction
172 TODO: reconcile
174 [TNC]This document proposes an information model to serve the
175 security automation use- cases outlined by the IETF SACM
176 workgroup.[/TNC]
178 [wandw]This draft was developed in response to the Call for
179 Contributions for the SACM Information Model sent to NIST
180 [IM-LIAISON-STATEMENT-NIST]. This draft proposes a notional
181 information model for endpoint posture assessment. It describes the
182 information needed to perform certain assessment activities and
183 relevant work that may be used as a basis for the development of
184 specific data models. The terms information model and data model
185 loosely align with the terms defined in RFC3444 [RFC3444].
187 The four primary activities to support this information model are:
189 1. Endpoint Identification
191 2. Endpoint Characterization
193 3. Endpoint Attribute Expression/Representation
194 4. Policy evaluation expression and results reporting
196 These activities are aimed at the level of the technology that
197 performs operations to support collection, evaluation, and reporting.
199 Review of the SACM Use Case [I-D.ietf-sacm-use-cases] usage scenarios
200 show a common set of business process areas that are critical to
201 understanding endpoint posture such that appropriate policies,
202 security capabilities, and decisions can be developed and
203 implemented.
205 For this information model we have chosen to focus on the following
206 business process areas:
208 o Endpoint Management
210 o Software Management
212 o Configuration Management
214 o Vulnerability Management
216 These management process areas are a way to connect the SACM use
217 cases and building blocks [I-D.ietf-sacm-use-cases] to the
218 organizational needs such that the definition of information
219 requirements has a clearly understood context.[/wandw]
221 [TNC]The proposed SACM information model offers a loose coupling
222 between providers and consumers of security information. A provider
223 can relay what it observes or infers, without knowing which consumers
224 will use the information, or how they will use it. A consumer need
225 not know exactly which provider generated a piece of information, or
226 by what method.
228 At the same time, a consumer *can* know these things, if necessary.
230 As things evolve, a provider can relay supplemental information.
231 Some consumers will understand and benefit from the supplemental
232 information; other consumers will not understand and will disregard
233 it.
235 The structure of each unit of information is extensible. The
236 arrangement of information units into a graph is also extensible; new
237 arrangements can be defined for new use cases.[/TNC]
239 2. Problem Statement
241 TODO: revise
243 [wandw]SACM requires a large and broad set of mission and business
244 processes, and to make the most effective of use of technology, the
245 same data must support multiple processes. The activities and
246 processes described within this document tend to build off of each
247 other to enable more complex characterization and assessment. In an
248 effort to create an information model that serves a common set of
249 management processes represented by the usage scenarios in the SACM
250 Use Cases document, we have narrowed down the scope of this
251 model.[/wandw] [What does "narrowed down the scope of this model"
252 mean? - LL]
254 Administrators can't get technology from disparate sources to work
255 together; they need information to make decisions, but the
256 information is not available. Everyone is collecting the same data,
257 but storing it as different information. Administrators therefore
258 need to collect data and craft their own information, which may not
259 be accurate or interoperable because it's customized by each
260 administrator, not shared. A standard information model enables
261 flexibility in collecting, storing, and sharing information despite
262 platform differences.
264 A way is needed to exchange information that (a) has breadth, meaning
265 the pieces of the notation are useful about a variety of endpoints
266 and software components, and (b) has longevity, meaning that the
267 pieces of the notation will stay useful over time.
269 When creating standards, it's not sufficient to go from requirements
270 directly to protocol; the standards must eliminate ambiguity in the
271 information transported. This is the purpose of information models
272 generally. The SACM problem space is about integrating many
273 information sources. This information model addresses the need to
274 integrate security components, support multiple data models, and
275 provide interoperability in a way that is platform agnostic, scales,
276 and works over time.
278 2.1. Mapping to SACM Use Cases
280 TODO: revise
282 [wandw]This information model directly corresponds to all four use
283 cases defined in the SACM Use Cases draft [I-D.ietf-sacm-use-cases].
284 It uses these use cases in coordination to achieve a small set of
285 well-defined tasks.
287 Sections [removed] thru [removed] address each of the process areas.
288 For each process area, a "Process Area Description" sub-section
289 represent an end state that is consistent with all the General
290 Requirements and many of the Use Case Requirements identified in the
291 requirements draft [I-D.camwinget-sacm-requirements].
293 The management process areas and supporting operations defined in
294 this memo directly support REQ004 Endpoint Discovery; REQ005-006
295 Attribute and Information Based Queries, and REQ0007 Asynchronous
296 Publication.
298 In addition, the operations that defined for each business process in
299 this memo directly correlate with the typical workflow identified in
300 the SACM Use Case document.[/wandw]
302 3. Conventions used in this document
304 3.1. Requirements Language
306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
307 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
308 document are to be interpreted as described in RFC 2119 [RFC2119].
310 4. Elements of the SACM Information Model
312 The proposed SACM Information Model contains several elements of the
313 architecture, including:
315 o Collectors, which may be internal (performed within the endpoint
316 itself) or external (performed outside of the endpoint, such as by
317 a hypervisor or remote sensor)
319 o Posture, in the form of posture attributes and evaluation results
321 o Additional information about the endpoint, such as a
322 representation of a software component, endpoint identity, user
323 identity, address, location, and authorization constraining the
324 endpoint
326 o History, a compilation of previously collected information [cek:
327 We don't model history per se. We have reports, which could be a
328 compilation of present information and/or of historical
329 information. I think it's helpful that the past and present are
330 modeled the same. They won't be implemented the same, but this is
331 an information model. So, can we remove this bullet?]
333 Figure 1 depicts the elements of the information model. Each element
334 has a meaning -- a denotation.
336 +---------+ +---------+ +--------+____________________
337 |Hardware | |Software | __________|Location|*_______________ |
338 |Component| |Component| | *+--------+* | |
339 +---------+ +---------+ | | |
340 |1 |1 | +----------+ | |
341 |* |* | ______|Credential|____________ | |
342 +---------+ +--------+ | | *+----------+* |* |* |
343 |Hardware | |Software| | | +---------+ +----+ |
344 |Instance | |Instance| | | |Network |_________|User| |
345 +---------+ +--------+ | | |Session |* 0..1+----+ |
346 |* |* *| *| |- - - - -| *|
347 | |___1+-----------+1______*|Network |__________+-------+
348 |____________| Endpoint |_____ |Interface|* 1..*|Address|
349 1| |0..1 | +---------+ +-------+
350 +-----------+ | 1|
351 |0..1 1| |* | |_____+-------------+
352 v| | |______| *|Authorization|
353 | | part-of> +-------------+
354 .................. |* .... | ........................................
355 ------------ +---------+ | ------------
356 |Collection|_>_|Attribute| | |Evaluation|__>__+----------+
357 |Guidance |1 *|Collector| |v |Guidance |1 *|Evaluator |
358 ------------ +---------+ | ------------ +----------+
359 |1 | 1|
360 v| | |v
361 |* |* *|
362 ===========_______________________============
363 +----------+ |Endpoint |1..* > *|Evaluation|
364 |Attribute/|________|Attribute|_____-----------_______|Result |
365 |Event |1..* 1|Assertion|* < *|Retention|* > *============
366 +----------+ =========== |Guidance |____ *|
367 *| -----------* | |
368 ----------- +---------+ | ======== |v |
369 |Reporting| |Report | |___>___*|Report|*____| |
370 |Guidance |__>__|Generator|___________| |______________|
371 -----------1 *+---------+1 > *========* <
373 -------------------------------------------------------------
374 1 Multiplicity symbols > < Direction of causation. For
375 0..1 found in UML 2 v ^ example, collection guidance
376 * class diagrams affects a collector.
377 1..*
378 ..... Above this line is the
379 monitorable world
380 -------------------------------------------------------------
382 Figure 1: Elements and Multiplicity
384 Note: UML 2 is specified by [UML].
386 The following subsections elaborate upon the elements found in the
387 two figures.
389 4.1. Endpoint
391 See the definition in the SACM Terminology for Security Assessment
392 [I-D.ietf-sacm-terminology].
394 In the model, an endpoint can be part of another endpoint. This
395 covers cases where multiple physical endpoints act as one endpoint.
396 The constituent endpoints may not be distinguishable by external
397 observation of network behavior.
399 For example, a hosting center may maintain a redundant set
400 (redundancy group) of multi-chassis setups to provide active
401 redundancy and load distribution on network paths to WAN gateways.
402 Multi-chassis link aggregation groups make the chassis appear as one
403 endpoint. Traditional security controls must be applied either to
404 physical endpoints or the redundancy groups they compose (and
405 occasionally both). Loss of redundancy is difficult to detect or
406 mitigate without specific posture information about the current state
407 of redundancy groups. Even if a physical endpoint (e.g. router) that
408 is part of a redundancy group is replaced, the redundancy group can
409 remain the same.
411 EDITOR'S NOTE: The endpoints to which an endpoint connects affects
412 its security posture. Should we add peer endpoints to the model?
414 4.1.1. Unique Endpoint Identifier
416 An organization needs to uniquely identify and label an endpoint,
417 whether the endpoint is enrolled or is discovered in the operational
418 environment. The identifier should be assigned by or used in the
419 enrollment process.
421 Here "unique" means one-to-one. In practice, uniqueness is not
422 always attainable. Even if an endpoint has a unique identifier, an
423 attribute collector may not always know it.
425 4.1.2. Endpoint Credential
427 An endpoint credential provides both identification and
428 authentication of the endpoint. For example, a credential may be an
429 X.509 certificate [RFC5280] and corresponding private key. [jmf-
430 this example should be formatted like the other examples in this
431 section]
432 Not all kinds of credentials are guaranteed to be unique.
434 4.1.3. Software Component
436 An endpoint contains and runs software components.
438 Some of the software components are assets. "Asset" is defined in
439 RFC4949 [RFC4949] as "a system resource that is (a) required to be
440 protected by an information system's security policy, (b) intended to
441 be protected by a countermeasure, or (c) required for a system's
442 mission."
444 An examination of software needs to consider both (a) software assets
445 and (b) software that may do harm. A posture attribute collector may
446 not know (a) from (b). It is useful to define Software Component as
447 the union of (a) and (b).
449 Examples of Software Assets:
451 o An application
453 o A patch
455 o The operating system kernel
457 o A boot loader
459 o Firmware that controls a disk drive
461 o A piece of JavaScript found in a web page the user visits
463 Examples of harmful software components:
465 o An entertainment app that contains malware
467 o A malicious executable
469 o A web page that contains malicious JavaScript
471 o A business application that shipped with a virus
473 4.1.3.1. Unique Software Identifier
475 Organizations need to be able to uniquely identify and label software
476 installed or run on an endpoint. Specifically, they need to know the
477 name, publisher, unique ID, and version; and any related patches. In
478 some cases the software's identity might be known a priori by the
479 organization; in other cases, a software identity might be first
480 detected by an organization when the software is first inventoried in
481 an operational environment. Due to this, it is important that an
482 organization have a stable and consistent means to identify software
483 found during collection.
485 A piece of software may have a unique identifier, such as a SWID tag
486 (ISO/IEC 19770).
488 4.1.4. Software Instance
490 Each copy of a piece of software is called a software instance. The
491 configuration of a software instance is regarded as part of the
492 software instance. Configuration can strongly affect security
493 posture.
495 4.1.5. Hardware Component
497 Hardware components may also be assets and or harmful. For example,
498 a USB port on a system may be disabled to prevent information flow
499 into our out of a particular system; this provides an additional
500 layer of protection that can complement software based protections.
501 Other such assets may include access to or modification of storage
502 media, hardware key stores, microphones and cameras. Like software
503 assets, we can consider these hardware components both from the
504 perspective of (a) an asset that needs protection and (b) an asset
505 that can be compromised in some way to do harm.
507 A hardware component is often designated by a manufacturer and a part
508 number.
510 4.1.6. Hardware Instance
512 A hardware instance is just an instance of a particular component. A
513 hardware instance often has a unique serial number.
515 Hardware instances may need to be modeled because (a) an endpoint may
516 have multiple instances of a hardware component, (b) a hardware
517 instance may be compromised, whereas other instances may remain
518 intact.
520 4.2. Internal Attribute Collector
522 An endpoint may also contain one or more internal collectors.
524 An internal attribute collector is an attribute collector that
525 collects posture attributes, values, or events from inside the
526 endpoint. In other words, the posture attributes and events are self
527 reported.
529 Example: a NEA posture collector. [RFC5209]
531 4.3. User
533 4.3.1. User Credential
535 An endpoint is often - but not always - associated with one or more
536 users.
538 A user's credential provides both identification and authentication
539 of the user.
541 4.4. Network Session
543 An endpoint generally has a connection to a network, referred to here
544 as a network session. A multi-homed endpoint may have more than one
545 network session.
547 4.4.1. Address
549 A network session generally is associated with addresses, such as MAC
550 and IP addresses.
552 These addresses are not necessarily globally unique. Therefore, an
553 address may be qualified with a scope. For example:
555 o A MAC address may be qualified with its layer-2 broadcast domain.
557 o An IP address may be qualified with its IP routing domain.
559 Other kinds of addresses may find application.
561 4.4.2. Authorizations
563 Authorizations determine what the endpoint can do with its network
564 session. Examples include:
566 o A RADIUS VLAN assignment [RFC3580]
568 o A router or firewall access control list (ACL)
570 o An IF-MAP access-request constellation
571 [TNC-IF-MAP-NETSEC-METADATA], which may determine how a firewall
572 treats the endpoint
574 4.5. Location
576 Location can be logical or physical, and may be pertinent to security
577 posture. For example, some endpoints may need to stay in protected
578 areas for their own protection.
580 Examples of location:
582 o The switch or access point to which the endpoint has authenticated
584 o The switch port where the endpoint is plugged in
586 o The location of the endpoint's IP address in the network topology
588 o The geographic location of the endpoint (typically self-reported)
590 o A user location (typically reported by a physical access control
591 system)
593 More than one of these may pertain to an endpoint. Endpoint has a
594 many-to-many relationship with Location.
596 A collector or other system may express location information as
597 posture attributes.
599 4.6. External Attribute Collector
601 An external collector is a collector that observes endpoints from
602 outside. [kkw-many of these [collectors] are actually configured and
603 operated to manage assets for reasons other than posture assessments.
604 it is critical to bring them into this, so i like it...but does it
605 matter if the [collector] isn't intended to support posture
606 assessment, but happens to have information that can be used by
607 posture assessment collection consumers? do we lump them together
608 with collectors that are intended to support posture assessment but
609 run external to the endpoint?] [jmf: ditto. The exampled below are
610 of things that would perform external collection].
612 [cek-to kkw's comment, I think the purpose here is to capture their
613 contribution to continuous monitoring. I don't see the need to
614 separate things whose primary job is monitoring from things whose
615 primary job is something else. Is there a need?]
617 [cek-to jmf's comment, that is what they are examples of; is a text
618 change needed?]
620 Examples:
622 o A RADIUS server whereby an endpoint has logged onto the network
624 o A network profiling system, which discovers and classifies network
625 nodes
627 o A Network Intrusion Detection System (NIDS) sensor
629 o A vulnerability scanner
631 o A hypervisor that peeks into the endpoint, the endpoint being a
632 virtual machine
634 o A management system that configures and installs software on the
635 endpoint
637 4.7. Endpoint Attribute Assertion
639 4.7.1. Form and Precise Meaning
641 An endpoint attribute assertion contains:
643 o One or more attribute-value pairs
645 o Optionally, one or more events
647 o A time interval
649 o Endpoint uniquely identified? True or false
651 It means:
653 o Over the specified time interval, there was an endpoint for which
654 all of the listed attribute-value pairs were true.
656 o For that endpoint, each event happened sometime during the time
657 interval. (This is meant as a normative definition of the
658 semantics of an endpoint attribute assertion.)
660 o If the "Endpoint uniquely identified" is true, the set of
661 attributes-value pairs together make this assertion apply to only
662 one endpoint.
664 The attributes can include posture attributes and identification
665 attributes. The model does not make a rigid distinction between the
666 two uses of attributes.
668 Some of the attributes may be multi-valued.
670 An Endpoint Attribute Assertion may or may not include a unique
671 endpoint identifier. Not every endpoint will have one. If there is
672 one, the SACM component that produces the Endpoint Attribute
673 Assertion will not necessarily know what it is.
675 4.7.2. Source
677 An Endpoint Attribute Assertion is typically provided by an attribute
678 collector. However, we envision some SACM components that produce
679 Endpoint Attribute Assertions from out-of-band sources, such as a
680 physical inventory system. We also envision some deriving Endpoint
681 Attribute Assertions from other Endpoint Attribute Assertions.
683 4.7.3. Example
685 For example, an attribute assertion might have these attribute-value
686 pairs:
688 mac-address = 01:23:45:67:89:ab
690 os = OS X
692 os-version = 10.6.8
694 This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran
695 OS X 10.6.8 throughout the specified time interval. A profiler might
696 have provided this assertion.
698 4.7.4. A Use Case
700 For example, Endpoint Attribute Assertions should help SACM
701 components to track an endpoint as it roams or stays stationary.
702 They must track it to track the endpoint's posture over time.
703 Tracking of an endpoint can employ many clues, such as:
705 The endpoint's MAC address
707 The authenticated identity (even if it identifies a user)
709 The location of the endpoint and the user
711 4.7.5. Posture Attribute
713 See the definition in the SACM Terminology for Security Assessment
714 [I-D.ietf-sacm-terminology].
716 Examples:
718 o A NEA posture attribute (PA) [RFC5209]
720 o A YANG model [RFC6020]
722 o An IF-MAP device-characteristics metadata item
723 [TNC-IF-MAP-NETSEC-METADATA]
725 4.7.6. Event
727 Examples:
729 o A structured syslog message [RFC5424]
731 o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
733 o A NetFlow message [RFC3954]
735 4.7.7. Difference between Attribute and Event
737 "Attribute" and "event" are often used fairly interchangeably. A
738 clear distinction makes the words more useful.
740 An *attribute* tends to stay true until something causes a change.
741 In contrast, an *event* occurs at a moment in time.
743 For a nontechnical example, "closed" is an attribute of a door. A
744 closed door tends to stay closed until something opens it (a breeze,
745 a person, or a dog).
747 The door's opening or closing is an event.
749 Similarly, "Host firewall is enabled?" may be modeled as an endpoint
750 attribute. Enabling or disabling the host firewall may be modeled as
751 an event. An endpoint's crashing also may be modeled as an event.
753 4.8. Evaluator
755 An evaluator can consume endpoint attribute assertions, previous
756 evaluations of posture attributes, or previous reports of evaluation
757 results. [kkw-i don't think this conflicts with the definition in the
758 terminology doc re: that evaluation tasks evaluate posture
759 attributes.]
761 [cek-I like the change. I think it *does* require a change in the
762 terminology doc, though.]
764 Example: a NEA posture validator [RFC5209]
766 [jmf- a NEA posture validator is not an example of this definition.
767 A NEA posture assessment is, maybe?]
769 [cek-Why isn't a NEA posture validator an example?]
771 4.9. Evaluation Result
773 See the definition in the SACM Terminology for Security Assessment
774 [I-D.ietf-sacm-terminology].
776 Example: a NEA access recommendation [RFC5793]
778 As Figure 1 shows, an Evaluation Result derives from one or more
779 Posture Attributes and Events.
781 An evaluator may be able to evaluate better if history is available.
782 This is a use case for retaining Posture Attributes and Events for a
783 time.
785 An Evaluation Result may be retained longer than the Endpoint
786 Attribute Assertions from which it derives. (Figure 1 does not show
787 this.) In the limiting case, Endpoint Attribute Assertions are not
788 retained. When as an Endpoint Attribute Assertion arrives, an
789 evaluator produces an Evaluation Result.
791 4.10. Report Generator
793 A report generator makes reports based on:
795 o Endpoint Attribute Assertions,
797 o Evaluation Results, and/or
799 o Other Reports (a weekly report may be created from daily reports)
801 It may summarize data continually, as the data arrives. It also may
802 summarize data in response to an ad hoc query.
804 4.11. Report
806 A Report summarizes:
808 o Endpoint Attribute Assertions,
810 o [kkw-if we state that a software asset is a type of posture
811 attribute, then a software inventory is nothing more than a report
812 that summarizes all software assets for an endpoint. i think this
813 makes much more sense than adding an object that is the software
814 inventory. contingent on adding the fact that an evaluator can
815 operate on posture attributes, evaluation results, or reports.]
817 o [cek - I like the move of saying that an inventory is a type of
818 report. Let's.]
820 o [cek - I like the move of defining a posture attribute whose value
821 is the identifier of a software component.]
823 o [cek - I'm not sure I'd say that a software asset is a type of
824 posture attribute, though. There's description and there's
825 reality. I'd tend to say that a posture attribute (always) a
826 partial description of an endpoint, and is the output of a posture
827 attribute collector. Suppose there's a stealthy piece of malware
828 that hasn't been detected. It's a software component, but is it a
829 posture attribute? I'm not sure how to talk about this.]
831 o Events, and/or
833 o Evaluation Results
835 A Report may routine or ad hoc.
837 Some reports may be machine readable. Machine readable summaries may
838 be consumable by automatic response systems (not part of SACM).
840 4.12. Organization?
842 [kkw-from a reporting standpoint there needs to be some concept like
843 organization or system. without this, there is no way to produce
844 result reports that can be acted upon to provide the insight or
845 accountability that almost all continuous monitoring instances are
846 trying to achieve. from a scoring or grading standpoint, an endpoint
847 needs to be associated with exactly one organization or system. it
848 can have a many to many relationship with other types of results
849 reporting "bins". is this important to include here? we had
850 organization as a core asset type for this reason, so i think it is a
851 key information element. but i also know that i do not want to define
852 all the different reporting types, so i am unsure.]
854 [cek-I had not thought of this at all. Would it make sense to treat
855 the organization and the bins as part of the guidance for creating
856 reports? Maybe not. We should discuss.]
858 4.13. Guidance
860 [jmf- the guidance sections need more detail. . .]
862 [cek - What is missing? We would welcome a critique or text.]
864 Guidance is generally configurable by human administrators.
866 4.13.1. Internal Collection Guidance
868 An internal collector may need guidance to govern what it collects
869 and when.
871 4.13.2. External Collection Guidance
873 An external collector may need guidance to govern what it collects
874 and when.
876 4.13.3. Evaluation Guidance
878 An evaluator typically needs Evaluation Guidance to govern what it
879 considers to be a good or bad security posture.
881 4.13.4. Retention Guidance
883 A SACM deployment may retain posture attributes, events, or
884 evaluation results for some time. Retention supports ad hoc
885 reporting and other use cases.
887 If information is retained, retention guidance controls what is
888 retained and for how long.
890 If two or more pieces of retention guidance apply to a piece of
891 information, the guidance calling for the longest retention should
892 take precedence.
894 Retained information may be stored in a Configuration Management
895 Database (CMDB), for example.
897 4.13.5. Reporting Guidance
899 A Reporting Task typically needs Reporting Guidance to govern the
900 reports it generates.
902 4.14. Provenance of Information
904 Each Posture Attribute, Event, Evaluation Result, and Report needs to
905 be labeled with its provenance (see Section 5.7).
907 5. Graph Model
909 TODO: Write text on how the information model above can be realized
910 in this kind of graph model.
912 The graph model describes how security information is structured,
913 related, and accessed. Control of operations to supply and/or access
914 the data is architecturally distinct from the structuring of the data
915 in the information model. Authorization may be applied by the
916 Control Plane (as defined in the SACM Architecture
917 [I-D.camwinget-sacm-architecture]) to requests for information from a
918 consumer or requests for publication from a provider, and may also be
919 applied by a provider to a direct request from a consumer.
921 This architecture addresses information structure independently of
922 the access/transport of that information. This separation enables
923 scalability, customizability, and extensibility. Access to provide
924 or consume information is particularly suited to publish/subscribe/
925 query data transport and data access control models.
927 This graph model is a framework that:
929 o Facilitates the definition of extensible data types that support
930 SACM's use cases
932 o Provides a structure for the defined data types to be exchanged
933 via a variety of data transport models
935 o Describes components used in information exchange, and the objects
936 exchanged
938 o Captures and organizes evolving information and information
939 relationships for multiple data publishers
941 o Provides access to the published information via publish, query,
942 and subscribe operations
944 o Leverages the knowledge and experience gained from incorporating
945 TNC IF-MAP into many disparate products that have to integrate and
946 share an information model in a scalable, extensible manner
948 5.1. Background: Graph Models
950 Knowledge is often represented with graph-based formalisms. A common
951 formalism defines a graph as follows:
953 o A set of *vertices*
955 o A set of *edges*, each connecting two vertices (technically, an
956 edge is an ordered pair of vertices)
958 o A set of zero or more *properties* attached to each vertices and
959 edges. Each property consists of a type and a optionally a value.
960 The type and the value are typically just strings
962 +------------------+ +-----------------+
963 | Id: 1 | parent-of |Id: 2 |
964 | Given name: Sue | --------------> |Given name: Ann |
965 | Family name: Wong| |Family name: Wong|
966 +------------------+ +-----------------+
968 A VERTEX AN EDGE A VERTEX
970 Figure 2: Knowledge represented by a graph
972 A pair of vertices connected by an edge is commonly referred to as a
973 triple that comprises subject, predicate and object. For example,
974 subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A
975 common language that uses this representation is the Resource
976 Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225].
978 5.2. Graph Model Overview
980 The proposed model, influenced by IF-MAP, is a labeled graph: each
981 vertex has a label.
983 A table of synonyms follows.
985 +----------------+-----------------+--------------------------------+
986 | Graph Theory | Graph Databases | IF-MAP and This Internet Draft |
987 +----------------+-----------------+--------------------------------+
988 | Vertex or Node | Node | - |
989 | Label | - | Identifier |
990 | Edge | Edge | Link |
991 | - | Property | Metadata Item |
992 +----------------+-----------------+--------------------------------+
994 In this mode, identifiers and metadata have hierarchical structure.
996 The graphical aspect makes this model well suited to non-hierarchical
997 relationships, such as connectivity in a computer network.
999 Hierarchical properties allow this model to accommodate structures
1000 such as YANG [RFC6020] data models.
1002 5.3. Identifiers
1004 Each identifier is an XML element. For extensibility, schemas use
1005 xsd:anyAttribute and such.
1007 Alternately, this model could be changed to use another hierarchical
1008 notation, such as JSON.
1010 Identifiers are unique: two different vertices cannot have equivalent
1011 identifiers.
1013 An identifier has a type. There is a finite, but extensible, set of
1014 identifier types. If the identifier is XML, the type is based on the
1015 XML schema.
1017 In IF-MAP, standard identifier types include IP address, MAC address,
1018 identity, and overlay network. Additional identifier types will need
1019 to be standardized for SACM use cases.
1021 Any number of metadata items can be attached to an identifier.
1023 Some identifiers, especially those relating to identity, address, and
1024 location, require the ability to specify an administrative domain
1025 (such as AD domain, L2 broadcast domain / L3 routing domain, or
1026 geographic domain) in order to differentiate between instances with
1027 the same name occurring in different realms.
1029 5.4. Links
1031 A link can be thought of as an ordered pair of identifiers.
1033 Any number of metadata items can be attached to a link.
1035 5.5. Metadata
1037 A metadata item is the basic unit of information, and is attached to
1038 an identifier or to a link.
1040 A given metadata item is an XML document. In IF-MAP metadata items
1041 are generally small. However, larger ones, such as YANG data models,
1042 can also fit. For extensibility, the XML schemas of metadata items
1043 use xsd:anyAttribute and such.
1045 Alternately, this model could be changed to use another hierarchical
1046 notation, such as JSON.
1048 A metadata item has a type. There is a finite, but extensible, set
1049 of metadata types. If the metadata item is XML, the type is based on
1050 the XML schema. An example metadata type is
1051 http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device-
1052 characteristic.
1054 TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
1055 and TNC IF-MAP Metadata for ICS Security [TNC-IF-MAP-ICS-METADATA]
1056 define many pertinent metadata types. More will need to be
1057 standardized for SACM use cases.
1059 5.6. Use for SACM
1061 Many of the information elements can be represented as vertices, and
1062 many of the relationships can be represented as edges.
1064 Identifiers are like database keys. For example, there would be
1065 identifiers for addresses, identities, unique endpoint identifiers,
1066 software component identifiers, and hardware component identifiers.
1067 The inventory of software instances and hardware instances within an
1068 endpoint might be expressed using a single YANG description, as a
1069 single metadata item in the graph. Where to put Endpoint Attribute
1070 Assertions, Evaluation Results, and the like is an open question.
1072 5.7. Provenance
1074 Provenance helps to protect the SACM ecosystem against a misled or
1075 malicious provider.
1077 The provenance of a metadata item includes:
1079 o The time when the item was produced
1081 o The component that produced the item, including its software and
1082 version
1084 o The policies that governed the producing component, with versions
1086 o The method used to produce the information (e.g., vulnerability
1087 scan)
1089 How provenance should be expressed is an open question. For
1090 reference, in IF-MAP provenance of a metadata item is expressed
1091 within the metadata item [TNC-IF-MAP-NETSEC-METADATA]. For example,
1092 there is a top-level XML attribute called "timestamp".
1094 It is critical that provenance be secure from tampering. How to
1095 achieve that security is out of scope of this document.
1097 5.8. Extensibility
1099 Anyone can define an identifier type or a metadata type, by creating
1100 an XML schema (or other specification). There is no need for a
1101 central authority. Some deployments may exercise administrative
1102 control over the permitted identifier types and metadata types;
1103 others may leave components free rein.
1105 A community of components can agree on and use new identifier and
1106 metadata types, if the administrators allow it. This allows rapid
1107 innovation. Intermediate software that conveys graph changes from
1108 one component to another does not need changes. Components that do
1109 not understand the new types do not need changes. Accordingly, a
1110 consumer normally ignores metadata types and identifier types it does
1111 not understand.
1113 As a proof point for this agility, the original use cases for TNC IF-
1114 MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] were addressed in TNC
1115 IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA].
1116 Some years later an additional, major set of use cases, TNC IF-MAP
1117 Metadata for ICS [TNC-IF-MAP-ICS-METADATA], were specified and
1118 implemented.
1120 6. SACM Usage Scenario Example
1122 TODO: this section needs to refer out to wherever the operations /
1123 generalized workflow content ends up
1125 This section illustrates the proposed SACM Information Model as
1126 applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations
1127 [I-D.ietf-sacm-use-cases]. The following subsections describe the
1128 elements (components and elements), graph model, and operations
1129 (sample workflow) required to support the Detection of Posture
1130 Deviations scenario.
1132 The Detection of Posture Deviations scenario involves multiple
1133 elements interacting to accomplish the goals of the scenario.
1134 Figure 1 illustrates those elements along with their major
1135 communication paths.
1137 6.1. Graph Model for Detection of Posture Deviation
1139 The following subsections contain examples of identifiers and
1140 metadata which would enable detection of posture deviation. These
1141 lists are by no means exhaustive - many other types of metadata would
1142 be enumerated in a data model that fully addressed this usage
1143 scenario.
1145 6.1.1. Components
1147 The proposed SACM Information Model contains three components, as
1148 defined in the SACM Architecture [I-D.camwinget-sacm-architecture]:
1149 Posture Attribute Information Provider, Posture Attribute Information
1150 Consumer, and Control Plane.
1152 In this example, the components are instantiated as follows:
1154 o The Posture Attribute Information Provider is an endpoint security
1155 service which monitors the compliance state of the endpoint and
1156 reports any deviations for the expected posture.
1158 o The Posture Attribute Information Consumer is an analytics engine
1159 which absorbs information from around the network and generates a
1160 "heat map" of which areas in the network are seeing unusually high
1161 rates of posture deviations.
1163 o The Control Plane is a security automation broker which receives
1164 subscription requests from the analytics engine and authorizes
1165 access to appropriate information from the endpoint security
1166 service.
1168 6.1.2. Identifiers
1170 To represent the elements listed above, the set of identifiers might
1171 include (but is not limited to):
1173 o Identity - a device itself, or a user operating a device,
1174 categorized by type of credential (e.g. username or X.509
1175 certificate [RFC5280])
1177 o Software asset
1179 o Network Session
1181 o Address - categorized by type of address (e.g. MAC address, IP
1182 address, Host Identity Protocol (HIP) Host Identity Tag (HIT)
1183 [RFC5201], etc.)
1185 o Task - categorized by type of task (e.g. internal collector,
1186 external collector, evaluator, or reporting task)
1188 o Result - categorized by type of result (e.g. evaluation result or
1189 report)
1191 o Guidance
1193 6.1.3. Metadata
1195 To characterize the elements listed above, the set of metadata types
1196 might include (but is not limited to):
1198 o Authorization metadata attached to an identity identifier, or to a
1199 link between a network session identifier and an identity
1200 identifier, or to a link between a network session identifier and
1201 an address identifier.
1203 o Location metadata attached to a link between a network session
1204 identifier and an address identifier.
1206 o Event metadata attached to an address identifier or an identity
1207 identifier of an endpoint, which would be made available to
1208 interested parties at the time of publication, but not stored
1209 long-term. For example, when a user disables required security
1210 software, an internal collector associated with an endpoint
1211 security service might publish guidance violation event metadata
1212 attached to the identity identifier of the endpoint, to notify
1213 consumers of the change in endpoint state.
1215 o Posture attribute metadata attached to an identity identifier of
1216 an endpoint. For example, when required security software is not
1217 running, an internal collector associated with an endpoint
1218 security service might publish posture attribute metadata attached
1219 to the identity identifier of the endpoint, to notify consumers of
1220 the current state of the endpoint.
1222 6.1.4. Relationships between Identifiers and Metadata
1224 Interaction between multiple sets of identifiers and metadata lead to
1225 some fairly common patterns, or "constellations", of metadata. For
1226 example, an authenticated-session metadata constellation might
1227 include a central network session with authorizations and location
1228 attached, and links to a user identity, an endpoint identity, a MAC
1229 address, an IP address, and the identity of the policy server that
1230 authorized the session, for the duration of the network session.
1232 These constellations may be independent of each other, or one
1233 constellation may be connected to another. For example, an
1234 authenticated-session metadata constellation may be created when a
1235 user connects an endpoint to the network; separately, an endpoint-
1236 posture metadata constellation may be created when an endpoint
1237 security system and other collectors gather and publish posture
1238 information related to an endpoint. These two constellations are not
1239 necessarily connected to each other, but may be joined if the
1240 component publishing the authenticated-session metadata constellation
1241 is able to link the network session identifier to the identity
1242 identifier of the endpoint.
1244 6.2. Workflow
1246 The workflow for exchange of information supporting detection of
1247 posture deviation, using a standard publish/subscribe/query transport
1248 model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or
1249 XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows:
1251 1. The analytics engine (Posture Assessment Information Consumer)
1252 establishes connectivity and authorization with the transport
1253 fabric, and subscribes to updates on posture deviations.
1255 2. The endpoint security service (Posture Assessment Information
1256 Provider) requests connection to the transport fabric.
1258 3. Transport fabric authenticates and establishes authorized
1259 privileges (e.g. privilege to publish and/or subscribe to
1260 security data) for the requesting components.
1262 4. The endpoint security service evaluates the endpoint, detects
1263 posture deviation, and publishes information on the posture
1264 deviation.
1266 5. The transport fabric notifies the analytics engine, based on its
1267 subscription of the new posture deviation information.
1269 Other components, such as access control policy servers or
1270 remediation systems, may also consume the posture deviation
1271 information provided by the endpoint security service.
1273 7. Acknowledgements
1275 Many of the specifications in this document have been developed in a
1276 public-private partnership with vendors and end-users. The hard work
1277 of the SCAP community is appreciated in advancing these efforts to
1278 their current level of adoption.
1280 Over the course of developing the initial draft, Henk Birkholz, Brant
1281 Cheikes, Matt Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt,
1282 and Steve Venema have contributed text to many sections of this
1283 document.
1285 8. IANA Considerations
1287 This memo includes no request to IANA.
1289 9. Security Considerations
1291 Posture Assessments need to be performed in a safe and secure manner.
1292 In that regard, there are multiple aspects of security that apply to
1293 the communications between components as well as the capabilities
1294 themselves. Due to time constraints, this information model only
1295 contains an initial listing of items that need to be considered with
1296 respect to security. This list is not exhaustive, and will need to
1297 be augmented as the model continues to be developed/refined.
1299 Initial list of security considerations include:
1301 Authentication: Every component and asset needs to be able to
1302 identify itself and verify the identity of other components
1303 and assets.
1305 Confidentiality: Communications between components need to be
1306 protected from eavesdropping or unauthorized collection.
1307 Some communications between components and assets may need to
1308 be protected as well.
1310 Integrity: The information exchanged between components needs to be
1311 protected from modification. some exchanges between assets
1312 and components will also have this requirement.
1314 Restricted Access: Access to the information collected, evaluated,
1315 reported, and stored should only be viewable/consumable to
1316 authenticated and authorized entities.
1318 The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF-
1319 MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
1320 document security considerations for sharing information via security
1321 automation. Most, and possibly all, of these considerations also
1322 apply to information shared via this proposed information model.
1324 10. References
1326 10.1. Normative References
1328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1329 Requirement Levels", BCP 14, RFC 2119, March 1997.
1331 10.2. Informative References
1333 [CCE] The National Institute of Standards and Technology,
1334 "Common Configuration Enumeration", 2014,
1335 .
1337 [CCI] United States Department of Defense Defense Information
1338 Systems Agency, "Control Correlation Identifier", 2014,
1339 .
1341 [CPE-WEBSITE]
1342 The National Institute of Standards and Technology,
1343 "Common Platform Enumeration", 2014,
1344 .
1346 [CVE-WEBSITE]
1347 The MITRE Corporation, "Common Vulnerabilities and
1348 Exposures", 2014, .
1350 [I-D.camwinget-sacm-architecture]
1351 Cam-Winget, N., Ford, B., llorenzin@juniper.net, l.,
1352 McDonald, I., and l. loxx@cisco.com, "Secure Automation
1353 and Continuous Monitoring (SACM) Architecture", draft-
1354 camwinget-sacm-architecture-00 (work in progress), June
1355 2014.
1357 [I-D.camwinget-sacm-requirements]
1358 Cam-Winget, N., "Secure Automation and Continuous
1359 Monitoring (SACM) Requirements", draft-camwinget-sacm-
1360 requirements-04 (work in progress), June 2014.
1362 [I-D.ietf-sacm-terminology]
1363 Waltermire, D., Montville, A., Harrington, D., and N. Cam-
1364 Winget, "Terminology for Security Assessment", draft-ietf-
1365 sacm-terminology-05 (work in progress), August 2014.
1367 [I-D.ietf-sacm-use-cases]
1368 Waltermire, D. and D. Harrington, "Endpoint Security
1369 Posture Assessment - Enterprise Use Cases", draft-ietf-
1370 sacm-use-cases-07 (work in progress), April 2014.
1372 [I-D.salowey-sacm-xmpp-grid]
1373 Salowey, J., llorenzin@juniper.net, l., Kahn, C., Pope,
1374 S., Appala, S., Woland, A., and N. Cam-Winget, "XMPP
1375 Protocol Extensions for Use in SACM Information
1376 Transport", draft-salowey-sacm-xmpp-grid-00 (work in
1377 progress), July 2014.
1379 [IM-LIAISON-STATEMENT-NIST]
1380 Montville, A., "Liaison Statement: Call for Contributions
1381 for the SACM Information Model to NIST", May 2014,
1382 .
1384 [ISO.18180]
1385 "Information technology -- Specification for the
1386 Extensible Configuration Checklist Description Format
1387 (XCCDF) Version 1.2", ISO/IEC 18180, 2013,
1388 .
1391 [ISO.19770-2]
1392 "Information technology -- Software asset management --
1393 Part 2: Software identification tag", ISO/IEC 19770-2,
1394 2009.
1396 [NISTIR-7275]
1397 Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring,
1398 "Specification for the Extensible Configuration Checklist
1399 Description Format (XCCDF) Version 1.2", NISTIR 7275r4,
1400 March 2013, .
1403 [NISTIR-7693]
1404 Wunder, J., Halbardier, A., and D. Waltermire,
1405 "Specification for Asset Identification 1.1", NISTIR 7693,
1406 June 2011,
1407 .
1410 [NISTIR-7694]
1411 Halbardier, A., Waltermire, D., and M. Johnson,
1412 "Specification for the Asset Reporting Format 1.1", NISTIR
1413 7694, June 2011,
1414 .
1417 [NISTIR-7695]
1418 Cheikes, B., Waltermire, D., and K. Scarfone, "Common
1419 Platform Enumeration: Naming Specification Version 2.3",
1420 NISTIR 7695, August 2011,
1421 .
1424 [NISTIR-7696]
1425 Parmelee, M., Booth, H., Waltermire, D., and K. Scarfone,
1426 "Common Platform Enumeration: Name Matching Specification
1427 Version 2.3", NISTIR 7696, August 2011,
1428 .
1431 [NISTIR-7697]
1432 Cichonski, P., Waltermire, D., and K. Scarfone, "Common
1433 Platform Enumeration: Dictionary Specification Version
1434 2.3", NISTIR 7697, August 2011,
1435 .
1438 [NISTIR-7698]
1439 Waltermire, D., Cichonski, P., and K. Scarfone, "Common
1440 Platform Enumeration: Applicability Language Specification
1441 Version 2.3", NISTIR 7698, August 2011,
1442 .
1445 [NISTIR-7848]
1446 Davidson, M., Halbardier, A., and D. Waltermire,
1447 "Specification for the Asset Summary Reporting Format
1448 1.0", NISTIR 7848, May 2012,
1449 .
1452 [OVAL-LANGUAGE]
1453 Baker, J., Hansbury, M., and D. Haynes, "The OVAL Language
1454 Specification version 5.10.1", January 2012,
1455 .
1457 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
1458 Architecture for Describing Simple Network Management
1459 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
1460 December 2002.
1462 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
1463 Simple Network Management Protocol (SNMP)", STD 62, RFC
1464 3416, December 2002.
1466 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
1467 Simple Network Management Protocol (SNMP)", STD 62, RFC
1468 3418, December 2002.
1470 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
1471 Information Models and Data Models", RFC 3444, January
1472 2003.
1474 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
1475 "IEEE 802.1X Remote Authentication Dial In User Service
1476 (RADIUS) Usage Guidelines", RFC 3580, September 2003.
1478 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version
1479 9", RFC 3954, October 2004.
1481 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1482 Syndication Format", RFC 4287, December 2005.
1484 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
1485 4949, August 2007.
1487 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
1488 "Host Identity Protocol", RFC 5201, April 2008.
1490 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
1491 Tardo, "Network Endpoint Assessment (NEA): Overview and
1492 Requirements", RFC 5209, June 2008.
1494 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1495 Housley, R., and W. Polk, "Internet X.509 Public Key
1496 Infrastructure Certificate and Certificate Revocation List
1497 (CRL) Profile", RFC 5280, May 2008.
1499 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
1501 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
1502 (PA) Protocol Compatible with Trusted Network Connect
1503 (TNC)", RFC 5792, March 2010.
1505 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
1506 A Posture Broker (PB) Protocol Compatible with Trusted
1507 Network Connect (TNC)", RFC 5793, March 2010.
1509 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
1510 Network Configuration Protocol (NETCONF)", RFC 6020,
1511 October 2010.
1513 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
1514 Bierman, "Network Configuration Protocol (NETCONF)", RFC
1515 6241, June 2011.
1517 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
1518 Transport Protocol over TLS (PT-TLS)", RFC 6876, February
1519 2013.
1521 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
1522 (PT) Protocol for Extensible Authentication Protocol (EAP)
1523 Tunnel Methods", RFC 7171, May 2014.
1525 [SP800-117]
1526 Quinn, S., Scarfone, K., and D. Waltermire, "Guide to
1527 Adopting and Using the Security Content Automation
1528 Protocol (SCAP) Version 1.2", SP 800-117, January 2012,
1529 .
1532 [SP800-126]
1533 Waltermire, D., Quinn, S., Scarfone, K., and A.
1534 Halbardier, "The Technical Specification for the Security
1535 Content Automation Protocol (SCAP): SCAP Version 1.2", SP
1536 800-126, September 2011,
1537 .
1540 [TNC-Architecture]
1541 Trusted Computing Group, ""TNC Architecture",
1542 Specification Version 1.5", May 2012.
1544 [TNC-IF-M-TLV-Binding]
1545 Trusted Computing Group, ""TNC IF-M: TLV Binding",
1546 Specification Version 1.0", May 2014.
1548 [TNC-IF-MAP-ICS-METADATA]
1549 Trusted Computing Group, ""TNC IF-MAP Metadata for ICS
1550 Security", Specification Version 1.0", May 2014.
1552 [TNC-IF-MAP-NETSEC-METADATA]
1553 Trusted Computing Group, ""TNC IF-MAP Metadata for Network
1554 Security", Specification Version 1.1", May 2012.
1556 [TNC-IF-MAP-SOAP-Binding]
1557 Trusted Computing Group, ""TNC IF-MAP Binding for SOAP",
1558 Specification Version 2.2", March 2014.
1560 [TNC-IF-T-TLS]
1561 Trusted Computing Group, ""TNC IF-T: Binding to TLS",
1562 Specification Version 2.0", February 2013.
1564 [TNC-IF-T-Tunneled-EAP]
1565 Trusted Computing Group, ""TNC IF-T: Protocol Bindings for
1566 Tunneled EAP Methods", Specification Version 2.0", May
1567 2014.
1569 [TNC-IF-TNCCS-TLV-Binding]
1570 Trusted Computing Group, ""TNC IF-TNCCS: TLV Binding",
1571 Specification Version 2.0", May 2014.
1573 [UML] Object Management Group, ""Unified Modeling Language TM
1574 (UML (R))", Version 2.4.1", August 2011.
1576 [W3C.REC-rdf11-concepts-20140225]
1577 Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1
1578 Concepts and Abstract Syntax", World Wide Web Consortium
1579 Recommendation REC-rdf11-concepts-20140225, February 2014,
1580 .
1582 [W3C.REC-soap12-part1-20070427]
1583 Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J.,
1584 Nielsen, H., Karmarkar, A., and Y. Lafon, "SOAP Version
1585 1.2 Part 1: Messaging Framework (Second Edition)", World
1586 Wide Web Consortium Recommendation REC-
1587 soap12-part1-20070427, April 2007,
1588 .
1590 10.3. URIs
1592 [1] https://github.com/OVALProject/Sandbox/blob/master/x-netconf-
1593 definitions-schema.xsd
1595 Appendix A. Security Automation with TNC IF-MAP
1597 A.1. What is Trusted Network Connect?
1599 Trusted Network Connect (TNC) is a vendor-neutral open architecture
1600 [TNC-Architecture] and a set of open standards for network security
1601 developed by the Trusted Computing Group (TCG). TNC standards
1602 integrate security components across end user systems, servers, and
1603 network infrastructure devices into an intelligent, responsive,
1604 coordinated defense. TNC standards have been widely adopted by
1605 vendors and customers; the TNC endpoint assessment protocols [TNC-IF-
1606 M-TLV-Binding][TNC-IF-TNCCS-TLV-Binding][TNC-IF-T-Tunneled-EAP][TNC-I
1607 F-T-TLS] were used as the base for the IETF NEA RFCs
1608 [RFC5792][RFC5793][RFC7171][RFC6876].
1610 Traditional information security architectures have separate silos
1611 for endpoint security, network security, server security, physical
1612 security, etc. The TNC architecture enables the integration and
1613 categorization of security telemetry sources via the information
1614 model contained in its Interface for Metadata Access Points (IF-MAP)
1615 [TNC-IF-MAP-SOAP-Binding]. IF-MAP provides a query-able repository
1616 of security telemetry that may be used for storage or retrieval of
1617 such data by multiple types of security systems and endpoints on a
1618 vendor-neutral basis. The information model underlying the IF-MAP
1619 repository covers, directly or indirectly, all of the security
1620 information types required to serve SACM use-cases.
1622 A.2. What is TNC IF-MAP?
1624 IF-MAP provides a standard client-server protocol for MAP clients to
1625 exchange security-relevant information via database server known as
1626 the Metadata Access Point or MAP. The data (known as "metadata")
1627 stored in the MAP is XML data. Each piece of metadata is tagged with
1628 a metadata type that indicates the meaning of the metadata and
1629 identifies an XML schema for it. Due to the XML language, the set of
1630 metadata types is easily extensible.
1632 The MAP is a graph database, not a relational database. Metadata can
1633 be associated with an identifier (e.g. the email address
1634 "user@example.com") or with a link between two identifiers (e.g. the
1635 link between MAC address 00:11:22:33:44:55 and IPv4 address
1636 192.0.2.1) where the link defines an association (for example: a
1637 relation or state) between the identifiers. These links between
1638 pairs of identifiers create an ad hoc graph of relationships between
1639 identifiers. The emergent structure of this graph reflects a
1640 continuously evolving knowledge base of security-related metadata
1641 that is shared between various providers and consumers.
1643 A.3. What is the TNC Information Model?
1645 The TNC Information Model underlying IF-MAP relies on the graph
1646 database architecture to enable a (potentially distributed) MAP
1647 service to act as a shared clearinghouse for information that
1648 infrastructure devices can act upon. The IF-MAP operations and
1649 metadata schema specifications (TNC IF-MAP Binding for SOAP
1650 [TNC-IF-MAP-SOAP-Binding], TNC IF-MAP Metadata for Network Security
1651 [TNC-IF-MAP-NETSEC-METADATA], and TNC IF-MAP Metadata for ICS
1652 Security [TNC-IF-MAP-ICS-METADATA]) define an extensible set of
1653 identifiers and data types.
1655 Each IF-MAP client may interact with the IF-MAP graph data store
1656 through three fundamental types of operation requests:
1658 o Publish, which may create, modify, or delete metadata associated
1659 with one or more identifiers and/or links in the graph
1661 o Search, which retrieves a selected sub-graph according to a set of
1662 search criteria
1664 o Subscribe, which allows a client to manage a set of search
1665 commands which asynchronously return selected sub-graphs when
1666 changes to that sub-graph are made by other IF-MAP clients
1668 The reader is invited to review the existing IF-MAP specification
1669 [TNC-IF-MAP-SOAP-Binding] for more details on the above graph data
1670 store operation requests and their associated arguments.
1672 The current IF-MAP specification provides a SOAP
1673 [W3C.REC-soap12-part1-20070427] binding for the above operations, as
1674 well as associated SOAP operations for managing sessions, error
1675 handling, etc.
1677 Appendix B. Text for Possible Inclusion in the Terminology Draft
1679 B.1. Terms and Definitions
1681 This section describes terms that have been defined by other RFCs and
1682 Internet Drafts, as well as new terms introduced in this document.
1684 B.1.1. Pre-defined and Modified Terms
1686 This section contains pre-defined terms that are sourced from other
1687 IETF RFCs and Internet Drafts. Descriptions of terms in this section
1688 will reference the original source of the term and will provide
1689 additional specific context for the use of each term in SACM. For
1690 sake of brevity, terms from [I-D.ietf-sacm-terminology] are not
1691 repeated here unless the original meaning has been changed in this
1692 document.
1694 Asset For this Information Model it is necessary to change the
1695 scope of the definition of asset from the one provided in
1696 [I-D.ietf-sacm-terminology]. Originally defined in [RFC4949]
1697 and referenced in [I-D.ietf-sacm-terminology] as "a system
1698 resource that is (a) required to be protected by an
1699 information system's security policy, (b) intended to be
1700 protected by a countermeasure, or (c) required for a system's
1701 mission." This definition generally relates to an "IT
1702 Asset", which in the context of this document is overly
1703 limiting. For use in this document, a broader definition of
1704 the term is needed to represent non-IT asset types as well.
1706 In [NISTIR-7693] an asset is defined as "anything that has
1707 value to an organization, including, but not limited to,
1708 another organization, person, computing device, information
1709 technology (IT) system, IT network, IT circuit, software
1710 (both an installed instance and a physical instance), virtual
1711 computing platform (common in cloud and virtualized
1712 computing), and related hardware (e.g., locks, cabinets,
1713 keyboards)." This definition aligns better with common
1714 dictionary definitions of the term and better fits the needs
1715 of this document.
1717 B.1.2. New Terms
1719 IT Asset Originally defined in [RFC4949] as "a system resource that
1720 is (a) required to be protected by an information system's
1721 security policy, (b) intended to be protected by a
1722 countermeasure, or (c) required for a system's mission."
1724 Security Content Automation Protocol (SCAP) According to SP800-126,
1725 SCAP, pronounced "ess-cap", is "a suite of specifications
1726 that standardize the format and nomenclature by which
1727 software flaw and security configuration information is
1728 communicated, both to machines and humans." SP800-117
1729 revision 1 [SP800-117] provides a general overview of SCAP
1730 1.2. The 11 specifications that comprise SCAP 1.2 are
1731 synthesized by a master specification, SP800-126 revision 2
1732 [SP800-126], that addresses integration of the specifications
1733 into a coherent whole. The use of "protocol" in its name is
1734 a misnomer, as SCAP defines only data models. SCAP has been
1735 adopted by a number of operating system and security tool
1736 vendors.
1738 Appendix C. Text for Possible Inclusion in the Architecture or Use
1739 Cases
1741 C.1. Introduction
1743 The posture of an endpoint is the status of the endpoint with respect
1744 to the security policies and risk models of the organization.
1746 A system administrator needs to be able to determine which elements
1747 of an endpoint have a security problem and which do not conform the
1748 organization's security policies. The CIO needs to be able to
1749 determine whether endpoints have security postures that conform to
1750 the organization's policies to ensure that the organization is
1751 complying with its fiduciary and regulatory responsibilities. The
1752 regulator or auditor needs to be able to assess the level of due
1753 diligence being achieved by an organization to ensure that all
1754 regulations and due diligence expectations are being met. The
1755 operator needs to understand which assets have deviated from
1756 organizational policies so that those assets can be remedied.
1758 Operators will focus on which endpoints are composed of specific
1759 assets with problems. CIO and auditors need a characterization of
1760 how an organization is performing as a whole to manage the posture of
1761 its endpoints. All of these actors need deployed capabilities that
1762 implement security automation standards in the form of data formats,
1763 interfaces, and protocols to be able to assess, in a timely and
1764 secure fashion, all assets on all endpoints within their enterprise.
1765 This information model provides a basis to identify the desirable
1766 characteristics of data models to support these scenarios. Other
1767 SACM specifications, such as the SACM Architecture, will describe the
1768 potential components of an interoperable system solution based on the
1769 SACM information model to address the requirements for scalability,
1770 timeliness, and security.
1772 C.2. Core Principles
1774 This information model is built on the following core principles:
1776 o Collection and Evaluation are separate tasks.
1778 o Collection and Evaluation can be performed on the endpoint, at a
1779 local server that communicates directly with the endpoint, or
1780 based on data queried from a back end data store that does not
1781 communicate directly with any endpoints.
1783 o Every entity (human or machine) that notifies, queries, or
1784 responds to any guidance, collection, or evaluator must have a way
1785 of identifying itself and/or presenting credentials.
1786 Authentication is a key step in all of the processes, and while
1787 needed to support the business processes, information needs to
1788 support authentication are not highlighted in this information
1789 model. There is already a large amount of existing work that
1790 defines information needs for authentication.
1792 o Policies are reflected in guidance for collection, evaluation, and
1793 reporting.
1795 o Guidance will often be generated by humans or through the use of
1796 transformations on existing automation data. In some cases,
1797 guidance will be generated dynamically based on shared information
1798 or current operational needs. As guidance is created it will be
1799 published to an appropriate guidance data store allowing guidance
1800 to be managed in and retrieved from convenient locations.
1802 o Operators of a continuous monitoring or security automation system
1803 will need to make decisions when defining policies about what
1804 guidance to use or reference. The guidance used may be directly
1805 associated with policy or may be queried dynamically based on
1806 associated metadata.
1808 o Guidance can be gathered from multiple data stores. It may be
1809 retrieved at the point of use or may be packaged and forwarded for
1810 later use. Guidance may be retrieved in event of a collection or
1811 evaluation trigger or it may be gathered ahead of time and stored
1812 locally for use/reference during collection and evaluation
1813 activities.
1815 C.3. Architecture Assumptions
1817 This information model will focus on WHAT information needs to be
1818 exchanged to support the business process areas. The architecture
1819 document is the best place to represent the HOW and the WHERE this
1820 information is used. In an effort to ensure that the data models
1821 derived from this information model scale to the architecture, four
1822 core architectural components need to be defined. They are
1823 producers, consumers, capabilities, and repositories. These elements
1824 are defined as follows:
1826 o Producers (e.g., Evaluation Producer) collect, aggregate, and/or
1827 derive information items and provide them to consumers. For this
1828 model there are Collection, Evaluation, and Results Producers.
1829 There may or may not be Guidance Producers.
1831 o Consumers (e.g., Collection Consumer) request and/or receive
1832 information items from producers for their own use. For this
1833 model there are Collection, Evaluation, and Results Consumers.
1834 There may or may not be Guidance Consumers.
1836 o Capabilities (e.g., Posture Evaluation Capability) take the input
1837 from one or more producers and perform some function on or with
1838 that information. For this model there are Collection Guidance,
1839 Collection, Evaluation Guidance, Evaluation, Reporting Guidance,
1840 and Results Reporting Capabilities.
1842 o Repositories (e.g., Enterprise Repository) store information items
1843 that are input to or output from Capabilities, Producers, and
1844 Consumers. For this model we refer to generic Enterprise and
1845 Guidance Repositories.
1847 Information that needs to be communicated by or made available to any
1848 of these components will be specified in each of the business process
1849 areas.
1851 In the most trivial example, illustrated in Figure 3, Consumers
1852 either request information from, or are notified by, Producers.
1854 +----------+ Request +----------+
1855 | <-----------------+ |
1856 | Producer | | Consumer |
1857 | +-----------------> |
1858 +----------+ Response +----------+
1860 +----------+ +----------+
1861 | | Notify | |
1862 | Producer +-----------------> Consumer |
1863 | | | |
1864 +----------+ +----------+
1866 Figure 3: Example Producer/Consumer Interactions
1868 As illustrated in Figure 4, writing and querying from data
1869 repositories are a way in which this interaction can occur in an
1870 asynchronous fashion.
1872 +----------+ +----------+
1873 | | | |
1874 | Producer | | Consumer |
1875 | | | |
1876 +-----+----+ +----^-----+
1877 | |
1878 Write | +------------+ | Query
1879 | | | |
1880 +-----> Repository +-------+
1881 | |
1882 +------------+
1884 Figure 4: Producer/Consumer Repository Interaction
1886 To perform an assessment, these elements are chained together. The
1887 diagram below is illustrative of this and process, and is meant to
1888 demonstrate WHAT basic information exchanges need to occur, while
1889 trying to maintain flexibility in HOW and WHERE they occur.
1891 For example:
1893 o the collection capability can reside on the endpoint or not.
1895 o the collection producer can be part of the collection capability
1896 or not.
1898 o a repository can be directly associated with a producer and/or an
1899 evaluator or stand on its own.
1901 o there can be multiple "levels" of producers and consumers.
1903 +-------------+
1904 |Evaluation |
1905 +-------------+ |Guidance +--+
1906 |Endpoint | |Capability | |
1907 +-------+ | +-------------+ |
1908 | | | |
1909 | +-------+-----+ +-----v-------+
1910 | Collection | |Evaluation |
1911 +-> Capability +--+--------+ |Capability |
1912 | | |Collection | +-----------+ +----------+
1913 | +------------+Producer | | |---| |
1914 | | | |Collection | |Evaluation|
1915 | | | |Consumer | |Producer |
1916 | +----+------+ +----^------+ +---+------+
1917 ++---------+ | | |
1918 |Collection| +-----v------+ +---+--------+ |
1919 |Guidance | | | |Collection | |
1920 |Capability| |Collection | |Producer | |
1921 | | |Consumer |-----| | |
1922 +----------+ +------------+ +------------+ |
1923 | Collection | |
1924 | Repository | |
1925 +------------+ |
1926 |
1927 +--------------+ +---------------+ |
1928 |Evaluation | |Evaluation | |
1929 |Results | |Consumer <-----+
1930 |Producer |-----------| |
1931 +-----+--------+ +---------------+
1932 | |Results Reporting|
1933 | |Capability |
1934 | +------------^----+
1935 | |
1936 +-----v--------+ +----+------+
1937 |Evaluation | |Reporting |
1938 |Results | |Guidance |
1939 |Consumer | |Repository |
1940 +---+----------+ +-----------+ +-------------+
1941 | | Results |
1942 +-----------------------------> Repository |
1943 | |
1944 +-------------+
1946 Figure 5: Producer/Consumer Complex Example
1948 This illustrative example in Figure 5 provides a set of information
1949 exchanges that need to occur to perform a posture assessment. The
1950 rest of this information model is using this set of exchanges based
1951 on these core architectural components as the basis for determining
1952 information elements.
1954 Appendix D. Text for Possible Inclusion in the Requirements Draft
1956 D.1. Problem Statement
1958 Scalable and sustainable collection, expression, and evaluation of
1959 endpoint information is foundational to SACM's objectives. To secure
1960 and defend one's network one must reliably determine what devices are
1961 on the network, how those devices are configured from a hardware
1962 perspective, what software products are installed on those devices,
1963 and how those products are configured. We need to be able to
1964 determine, share, and use this information in a secure, timely,
1965 consistent, and automated manner to perform endpoint posture
1966 assessments.
1968 D.2. Problem Scope
1970 The goal of this iteration of the information model is to define the
1971 information needs for an organization to effectively monitor the
1972 endpoints operating on their network, the software installed on those
1973 endpoints, and the configuration of that software. Once we have
1974 those three business processes in place, we can identify vulnerable
1975 endpoints in a very efficient manner.
1977 The four business process areas represent a large set of tasks that
1978 support endpoint posture assessment. In an effort to address the
1979 most basic and foundational needs, we have also narrowed down the
1980 scope inside of each of the business processes to a set of defined
1981 tasks that strive to achieve specific results in the operational
1982 environment and the organization. These tasks are:
1984 1. Define the assets. This is what we want to know about an asset.
1985 For instance, organizations will want to know what software is
1986 installed and its many critical security attributes such as patch
1987 level.
1989 2. Resolve what assets compose an endpoint. This requires
1990 populating the data elements and attributes needed to exchange
1991 information pertaining to the assets composing an endpoint.
1993 3. Express what expected values for the data elements and attributes
1994 need to be evaluated against the actual collected instances of
1995 asset data. This is how an organization can express its policy
1996 for an acceptable data element or attribute value. A system
1997 administrator can also identify specific data elements and
1998 attributes that represent problems, such as vulnerabilities, that
1999 need to be detected on an endpoint.
2001 4. Evaluate the collected instances of the asset data against those
2002 expressed in the policy.
2004 5. Report the results of the evaluation.
2006 Appendix E. Text With No Clear Home Yet
2008 E.1. Operations
2010 Operations that may be carried out the proposed SACM Information
2011 Model are:
2013 o Publish data: Security information is made available in the
2014 information model when a component publishes data to it.
2016 o Subscribe to data: A component seeking to consume an on-going
2017 stream of security information "subscribes" to such data from the
2018 information model.
2020 o Query: This operation enables a component to request a specific
2021 set of security data regarding a specific asset (such as a
2022 specific user endpoint).
2024 The subscribe capability will allow SACM components to monitor for
2025 selected security-related changes in the graph data store without
2026 incurring the performance penalties associated with polling for such
2027 changes.
2029 E.1.1. Generalized Workflow
2031 The proposed SACM Information Model would be most commonly used with
2032 a suitable transport protocol for collecting and distributing
2033 security data across appropriate network platforms and endpoints.
2034 The information model is transport agnostic and can be used with its
2035 native transport provided by IF-MAP or by other data transport
2036 protocols such as the recently proposed XMPP-Grid.
2038 1. A Posture Assessment Information Consumer (Consumer) establishes
2039 connectivity and authorization with the transport fabric.
2041 2. A Posture Assessment Information Provider (Provider) with a
2042 source of security data requests connection to the transport
2043 fabric.
2045 3. Transport fabric authenticates and establishes authorized
2046 privileges (e.g. privilege to publish and/or subscribe to
2047 security data) for the requesting components.
2049 4. Components may either publish security data, subscribe to
2050 security data, query for security data, or any combination of
2051 these operations.
2053 Any component sharing information - either as Provider or Consumer -
2054 may do so on a one-to-one, one-to-many and/or many-to-many meshed
2055 basis.
2057 E.2. From Information Needs to Information Elements
2059 The previous sections highlighted information needs for a set of
2060 management process areas that use posture assessment to achieve
2061 organizational security goals. A single information need may be made
2062 up of multiple information elements. Some information elements may
2063 be required for two different process areas, resulting in two
2064 different requirements. In an effort to support the main idea of
2065 collect once and reuse the data to support multiple processes, we try
2066 to define a singular set of information elements that will support
2067 all the associated information needs.
2069 E.3. Information Model Elements
2071 TODO: Kim to pull up relevant content into section 4 / Elements
2073 Traditionally, one would use the SACM architecture to define
2074 interfaces that required information exchanges. Identified
2075 information elements would then be based on those exchanges. Because
2076 the SACM architecture document is still in the personal draft stage,
2077 this information model uses a different approach to the
2078 identification of information elements. First it lists the four main
2079 endpoint posture assessment activities. Then it identifies
2080 management process areas that use endpoint posture assessment to
2081 achieve organizational security objectives. These process areas were
2082 then broken down into operations that mirrored the typical workflow
2083 from the SACM Use Cases draft [I-D.ietf-sacm-use-cases]. These
2084 operations identify architectural components and their information
2085 needs. In this section, information elements derived from those
2086 information needs are mapped back to the four main activities listed
2087 above.
2089 The original liaison statement [IM-LIAISON-STATEMENT-NIST] requested
2090 contributions for the SACM information model in the four areas
2091 described below. Based on the capabilities defined previously in
2092 this document, the requested areas alone do not provide a sufficient
2093 enough categorization of the necessary information model elements.
2094 The following sub-sections directly address the requested areas as
2095 follows:
2097 1. Endpoint Identification
2099 A. Appendix E.3.1 Asset Identifiers: Describes identification of
2100 many different asset types including endpoints.
2102 2. Endpoint Characterization
2104 A. Appendix E.3.3 Endpoint characterization: This directly maps
2105 to the requested area.
2107 3. Endpoint Attribute Expression/Representation
2109 A. Appendix E.3.4 Posture Attribute Expression: This corresponds
2110 to the first part of "Endpoint Attribute Expression/
2111 Representation."
2113 B. Appendix E.3.5 Actual Value Representation: This corresponds
2114 to the second part of "Endpoint Attribute Expression/
2115 Representation."
2117 4. Policy evaluation expression and results reporting
2119 A. Appendix E.3.6 Evaluation Guidance: This corresponds to the
2120 first part of "Policy evaluation expression and results
2121 reporting."
2123 B. Appendix E.3.7 Evaluation Result Reporting: corresponds to
2124 the second part of "Policy evaluation expression and results
2125 reporting."
2127 Additionally, Appendix E.3.2 Other Identifiers: describes other
2128 important identification concepts that were not directly requested by
2129 the liaison statement.
2131 Per the liaison statement, each subsection references related work
2132 that provides a basis for potential data models. Some analysis is
2133 also included for each area of related work on how directly
2134 applicable the work is to the SACM efforts. In general, much of the
2135 related work does not fully address the general or use case-based
2136 requirements for SACM, but they do contain some parts that can be
2137 used as the basis for data models that correspond to the information
2138 model elements. In these cases additional work will be required by
2139 the WG to adapt the specification. In some cases, existing work can
2140 largely be used in an unmodified fashion. This is also indicated in
2141 the analysis. Due to time constraints, the work in this section is
2142 very biased to previous work supported by the authors and does not
2143 reflect a comprehensive listing. An attempt has been made where
2144 possible to reference existing IETF work. Additional research and
2145 discussion is needed to include other related work in standards and
2146 technology communities that could and should be listed here. The
2147 authors intend to continue this work in subsequent revisions of this
2148 draft.
2150 Where possible when selecting and developing data models in support
2151 of these information model elements, extension points and IANA
2152 registries SHOULD be used to provide for extensibility which will
2153 allow for future data models to be addressed.
2155 E.3.1. Asset Identifiers
2157 In this context an "asset" refers to "anything that has value to an
2158 organization" (see [NISTIR-7693]). This use of the term "asset" is
2159 broader than the current definition in [I-D.ietf-sacm-terminology].
2160 To support SACM use cases, a number of different asset types will
2161 need to addressed. For each type of asset, one or more type of asset
2162 identifier will be needed for use in establishing contextual
2163 relationships within the SACM information model. The following asset
2164 types are referenced or implied by the SACM use cases:
2166 Endpoint: Identifies an individual endpoint for which posture is
2167 collected and evaluated.
2169 Hardware: Identifies a given type of hardware that may be installed
2170 within an endpoint.
2172 Software: Identifies a given type of software that may be installed
2173 within an endpoint.
2175 Network: Identifies a network for which a given endpoint may be
2176 connected or request a connection to.
2178 Organization: Identifies an organizational unit.
2180 Person: Identifies an individual, often within an organizational
2181 context.
2183 E.3.1.1. Related Work
2184 E.3.1.1.1. Asset Identification
2186 The Asset Identification specification [NISTIR-7693] is an XML-based
2187 data model that "provides the necessary constructs to uniquely
2188 identify assets based on known identifiers and/or known information
2189 about the assets." Asset identification plays an important role in
2190 an organization's ability to quickly correlate different sets of
2191 information about assets. The Asset Identification specification
2192 provides the necessary constructs to uniquely identify assets based
2193 on known identifiers and/or known information about the assets.
2194 Asset Identification provides a relatively flat and extensible model
2195 for capturing the identifying information about a one or more assets,
2196 and also provides a way to represent relationships between assets.
2198 The model is organized using an inheritance hierarchy of specialized
2199 asset types/classes (see Figure 6), providing for extension at any
2200 level of abstraction. For a given asset type, a number of properties
2201 are defined that provide for capturing identifying characteristics
2202 and the referencing of namespace qualified asset identifiers, called
2203 "synthetic IDs."
2205 The following figure illustrates the class hierarchy defined by the
2206 Asset Identification specification.
2208 asset
2209 +-it-asset
2210 | +-circuit
2211 | +-computing-device
2212 | +-database
2213 | +-network
2214 | +-service
2215 | +-software
2216 | +-system
2217 | +-website
2218 +-data
2219 +-organization
2220 +-person
2222 Figure 6: Asset Identification Class Hierarchy
2224 This table presents a mapping of notional SACM asset types to those
2225 asset types provided by the Asset Identification specification.
2227 +--------------+------------------+---------------------------------+
2228 | SACM Asset | Asset | Notes |
2229 | Type | Identification | |
2230 | | Type | |
2231 +--------------+------------------+---------------------------------+
2232 | Endpoint | computing-device | This is not a direct mapping |
2233 | | | since a computing device is not |
2234 | | | required to have network- |
2235 | | | connectivity. Extension will be |
2236 | | | needed to define a directly |
2237 | | | aligned endpoint asset type. |
2238 +--------------+------------------+---------------------------------+
2239 | Hardware | Not Applicable | The concept of hardware is not |
2240 | | | addressed by the asset |
2241 | | | identification specification. |
2242 | | | An extension can be created |
2243 | | | based on the it-asset class to |
2244 | | | address this concept. |
2245 +--------------+------------------+---------------------------------+
2246 | Software | software | Direct mapping. |
2247 +--------------+------------------+---------------------------------+
2248 | Network | network | Direct mapping. |
2249 +--------------+------------------+---------------------------------+
2250 | Organization | organization | Direct mapping. |
2251 +--------------+------------------+---------------------------------+
2252 | Person | person | Direct mapping. |
2253 +--------------+------------------+---------------------------------+
2255 Table 1: Mapping of SACM to Asset Identification Asset Types
2257 This specification has been adopted by a number of SCAP validated
2258 products. It can be used to address asset identification and
2259 categorization needs within SACM with minor modification.
2261 E.3.1.2. Endpoint Identification
2263 An unique name for an endpoint. This is a foundational piece of
2264 information that will enable collected posture attributes to be
2265 related to the endpoint from which they were collected. It is
2266 important that this name either be created from, provide, or be
2267 associated with operational information (e.g., MAC address, hardware
2268 certificate) that is discoverable from the endpoint or its
2269 communications on the network. It is also important to have a method
2270 of endpoint identification that can persist across network sessions
2271 to allow for correlation of collected data over time.
2273 E.3.1.2.1. Related Work
2275 The previously introduced asset identification specification (see
2276 Appendix E.3.1.1.1 provides a basis for endpoint identification using
2277 the "computing-device" class. While the meaning of this class is
2278 broader than the current definition of an endpoint in the SACM
2279 terminology [I-D.ietf-sacm-terminology], either that class or an
2280 appropriate sub-class extension can be used to capture identification
2281 information for various endpoint types.
2283 E.3.1.3. Software Identification
2285 A unique name for a unit of installable software. Software names
2286 should generally represent a unique release or installable version of
2287 software. Identification approaches should allow for identification
2288 of commercially available, open source, and organizationally
2289 developed custom software. As new software releases are created, a
2290 new software identifier should be created by the releasing party
2291 (e.g., software creator, publisher, licensor). Such an identifier is
2292 useful to:
2294 o Relate metadata that describes the characteristics of the unit of
2295 software, potentially stored in a repository of software
2296 information. Typically, the software identifier would be used as
2297 an index into such a repository.
2299 o Indicate the presence of the software unit on a given endpoint.
2301 o To determine what endpoints are the targets for an assessment
2302 based on what software is installed on that endpoint.
2304 o Define guidance related to a software unit that represents
2305 collection, evaluation, or other automatable policies.
2307 In general, an extensible method of software identification is needed
2308 to provide for adequate coverage and to address legacy identification
2309 approaches. Use of an IANA registry supporting multiple software
2310 identification methods would be an ideal way forward.
2312 E.3.1.3.1. Related Work
2314 While we are not aware of a one-size-fits-all solution for software
2315 identification, there are two existing specifications that should be
2316 considered as part of the solution set. They are described in the
2317 following subsections.
2319 E.3.1.3.1.1. Common Platform Enumeration
2321 E.3.1.3.1.1.1. Background
2323 The Common Platform Enumeration (CPE) [CPE-WEBSITE] is composed of a
2324 family of four specification that are layered to build on lower-level
2325 functionality. The following describes each specification:
2327 1. CPE Naming: A standard machine-readable format [NISTIR-7695] for
2328 encoding names of IT products and platforms. This defines the
2329 notation used to encode the vendor, software name, edition,
2330 version and other related information for each platform or
2331 product. With the 2.3 version of CPE, a second, more advanced
2332 notation was added to the original colon-delimited notation for
2333 CPE naming.
2335 2. CPE Matching: A set of procedures [NISTIR-7696] for comparing
2336 names. This describes how to compare two CPE names to one
2337 another. It describes a logical method that ensures that
2338 automated systems comparing two CPE names would arrive at the
2339 same conclusion.
2341 3. CPE Applicability Language: An XML-based language [NISTIR-7698]
2342 for constructing "applicability statements" that combine CPE
2343 names with simple logical operators.
2345 4. CPE Dictionary: An XML-based catalog format [NISTIR-7697] that
2346 enumerates CPE Names and associated metadata. It details how to
2347 encode the information found in a CPE Dictionary, thereby
2348 allowing multiple organizations to maintain compatible CPE
2349 Dictionaries.
2351 The primary use case of CPE is for exchanging software inventory
2352 data, as it allows the usage of unique names to identify software
2353 platforms and products present on an endpoint. The NIST currently
2354 maintains and updates a dictionary of all agreed upon CPE names, and
2355 is responsible for ongoing maintenance of the standard. Many of the
2356 names in the CPE dictionary have been provided by vendors and other
2357 3rd-parties.
2359 While the effort has seen wide adoption, most notably within the US
2360 Government, a number of critical flaws have been identified. The
2361 most critical issues associated with the effort are:
2363 o Because there is no requirement for vendors to publish their own,
2364 official CPE names, CPE necessarily requires one or more
2365 organizations for curation. This centralized curation requirement
2366 ensures that the effort has difficulty scaling.
2368 o Not enough primary source vendors provide platform and product
2369 naming information. As a result, this pushes too much of the
2370 effort out onto third-party groups and non-authoritative
2371 organizations. This exacerbates the ambiguity in names used for
2372 identical platforms and products and further reduces the utility
2373 of the effort.
2375 E.3.1.3.1.1.2. Applicability to Software Identification
2377 The Common Platform Enumeration (CPE) Naming specification version
2378 2.3 defines a scheme for human-readable standardized identifiers of
2379 hardware and software products.
2381 CPE names are the identifier format for software and hardware
2382 products used in SCAP 1.2 and is currently adopted by a number of
2383 SCAP product vendors.
2385 CPE names can be directly referenced in the asset identification
2386 software class (see Appendix E.3.1.1.1.)
2388 Although relevant, CPE has an unsustainable maintenance "tail" due to
2389 the need for centralized curation and naming-consistency enforcement.
2390 Its mention in this document is to support the historic inclusion of
2391 CPE as part of SCAP and implementation of this specification in a
2392 number of security processes and products. Going forward, software
2393 identification (SWID) tags are recommended as a replacement for CPE.
2394 To this end, work has been started to align both efforts to provide
2395 translation for software units identified using SWID tags to CPE
2396 Names. This translation would allow tools that currently use CPE-
2397 based identifiers to map to SWID identifiers during a transition
2398 period.
2400 E.3.1.3.1.2. Software Identification (SWID) Tags
2402 The software identification tag specification [ISO.19770-2] is an
2403 XML-based data model that is used to describe a unit of installable
2404 software. A SWID tag contains data elements that:
2406 o Identify a specific unit of installable software,
2408 o Enable categorization of the software (e.g., edition, bundle),
2410 o Identification and hashing of software artifacts (e.g.,
2411 executables, shared libraries),
2413 o References to related software and dependencies, and
2415 o Inclusion of extensible metadata.
2417 SWID tags can be associated with software installation media,
2418 installed software, software updates (e.g., service packs, patches,
2419 hotfixes), and redistributable components. SWID tags also provide
2420 for a mechanism to relate these concepts to each other. For example,
2421 installed software can be related back to the original installation
2422 media, patches can be related to the software that they patch, and
2423 software dependencies can be described for required redistributable
2424 components. SWID tags are ideally created at build-time by the
2425 software creator, publisher or licensor; are bundled with software
2426 installers; and are deployed to an endpoint during software
2427 installation.
2429 SWID tags should be considered for two primary uses:
2431 1. As the data format for exchanging descriptive information about
2432 software products, and
2434 2. As the source of unique identifiers for installed software.
2436 In addition to usage for software identification, a SWID tag can
2437 provide the necessary data needed to target guidance based on
2438 included metadata, and to support verification of installed software
2439 and software media using cryptographic hashes. This added
2440 information increases the value of using SWID tags as part of the
2441 larger security automation and continuous monitoring solution space.
2443 E.3.1.4. Hardware Identification
2445 Due to the time constraints, research into information elements and
2446 related work for identifying hardware is not included in this
2447 revision of the information model.
2449 E.3.2. Other Identifiers
2451 In addition to identifying core asset types, it is also necessary to
2452 have stable, globally unique identifiers to represent other core
2453 concepts pertaining to posture attribute collection and evaluation.
2454 The concept of "global uniqueness" ensures that identifiers provided
2455 by multiple organization do not collide. This may be handled by a
2456 number of different mechanisms (e.g., use of namespaces).
2458 E.3.2.1. Platform Configuration Item Identifier
2460 A name for a low-level, platform-dependent configuration mechanism as
2461 determined by the authoritative primary source vendor. New
2462 identifiers will be created when the source vendor makes changes to
2463 the underlying platform capabilities (e.g., adding new settings,
2464 replacing old settings with new settings). When created each
2465 identifier should remain consistent with regards to what it
2466 represents. Generally, a change in meaning would constitute the
2467 creation of a new identifier.
2469 For example, if the configuration item is for "automatic execution of
2470 code", then the platform vendor would name the low-level mechanism
2471 for their platform (e.g., autorun for mounted media).
2473 E.3.2.1.1. Related Work
2475 E.3.2.1.1.1. Common Configuration Enumeration
2477 The Common Configuration Enumeration (CCE) [CCE] is an effort managed
2478 by NIST. CCE provides a unique identifier for platform-specific
2479 configuration items that facilitates fast and accurate correlation of
2480 configuration items across multiple information sources and tools.
2481 CCE does this by providing an identifier, a human readable
2482 description of the configuration control, parameters needed to
2483 implement the configuration control, various technical mechanisms
2484 that can be used to implement the configuration control, and
2485 references to documentation that describe the configuration control
2486 in more detail.
2488 By vendor request, NIST issues new blocks of CCE identifiers.
2489 Vendors then populate the required fields and provided the details
2490 back to NIST for publication in the "CCE List", a consolidated
2491 listing of assigned CCE identifiers and associated data. Many
2492 vendors also include references to these identifiers in web pages,
2493 SCAP content, and prose configuration guides they produce.
2495 CCE the identifier format for platform specific configuration items
2496 in SCAP and is currently adopted by a number of SCAP product vendors.
2498 While CCE is largely supported as a crowd-sourced effort, it does
2499 rely on a central point of coordination for assignment of new CCE
2500 identifiers. This approach to assignment requires a single
2501 organization, currently NIST, to manage allocations of CCE
2502 identifiers which doesn't scale well and introduces sustainability
2503 challenges for large volumes of identifier assignment. If this
2504 approach is used going forward by SACM, a namespaced approach is
2505 recommended for identifier assignment that allows vendors to manage
2506 their own namespace of CCE identifiers. This change would require
2507 additional work to specify and implement.
2509 E.3.2.1.1.2. Open Vulnerability and Assessment Language
2511 E.3.2.1.1.2.1. Background
2513 The Open Vulnerability and Assessment Language (OVAL(R)) is an XML
2514 schema-based data model developed as part of a public-private
2515 information security community effort to standardize how to assess
2516 and report upon the security posture of endpoints. OVAL provides an
2517 established framework for making assertions about an endpoint's
2518 posture by standardizing the three main steps of the assessment
2519 process:
2521 1. representing the current endpoint posture;
2523 2. analyzing the endpoint for the presence of the specified posture;
2524 and
2526 3. representing the results of the assessment.
2528 OVAL facilitates collaboration and information sharing among the
2529 information security community and interoperability among tools.
2530 OVAL is used internationally and has been implemented by a number of
2531 operating system and security tools vendors.
2533 The following figure illustrates the OVAL data model.
2535 +------------+
2536 +-----------------+ | Variables |
2537 | Common <---+ |
2538 +--------> | +------------+
2539 | | | +------------+
2540 | | <---+ Directives |
2541 | +--------^----^---+ | |
2542 | | | +--------+---+
2543 | | +-----+ |
2544 | | | |
2545 | +--------+--------+ | |
2546 | | System | | |
2547 | | Characteristics | | |
2548 +------+------+ | | | +--------v---+
2549 | Definitions | | | | | Results |
2550 | | +--------^--------+ +-+ |
2551 | | | | |
2552 | | +------------+ |
2553 +------^------+ +-------+----+
2554 | |
2555 +--------------------------------------+
2557 Note: The direction of the arrows indicate a model dependency
2559 Figure 7: The OVAL Data Model
2561 The OVAL data model [OVAL-LANGUAGE], visualized in Figure 7, is
2562 composed of a number of different components. The components are:
2564 o Common: Constructs, enumerations, and identifier formats that are
2565 used throughout the other model components.
2567 o Definitions: Constructs that describe assertions about system
2568 state. This component also includes constructs for internal
2569 variable creation and manipulation through a variety of functions.
2570 The core elements are:
2572 * Definition: A collection of logical statements that are
2573 combined to form an assertion based on endpoint state.
2575 * Test(platform specific): A generalized construct that is
2576 extended in platform schema to describe the evaluation of
2577 expected against actual state.
2579 * Object(platform specific): A generalized construct that is
2580 extended in platform schema to describe a collectable aspect of
2581 endpoint posture.
2583 * State(platform specific): A generalized construct that is
2584 extended in platform schema to describe a set of criteria for
2585 evaluating posture attributes.
2587 o Variables: Constructs that allow for the parameterization of the
2588 elements used in the Definitions component based on externally
2589 provided values.
2591 o System Characteristics: Constructs that represent collected
2592 posture from one or more endpoints. This element may be embedded
2593 with the Results component, or may be exchanged separately to
2594 allow for separate collection and evaluation. The core elements
2595 of this component are:
2597 * CollectedObject: Provides a mapping of collected Items to
2598 elements defined in the Definitions component.
2600 * Item(platform specific): A generalized construct that is
2601 extended in platform schema to describe specific posture
2602 attributes pertaining to an aspect of endpoint state.
2604 o Results: Constructs that represent the result of evaluating
2605 expected state (state elements) against actual state (item
2606 elements). It includes the true/false evaluation result for each
2607 evaluated Definition and Test. Systems characteristics are
2608 embedded as well to provide low-level posture details.
2610 o Directives: Constructs that enable result reporting detail to be
2611 declared, allowing for result production to customized.
2613 End-user organizations and vendors create assessment guidance using
2614 OVAL by creating XML instances based on the XML schema implementation
2615 of the OVAL Definitions model. The OVAL Definitions model defines a
2616 structured identifier format for each of the Definition, Test,
2617 Object, State, and Item elements. Each instantiation of these
2618 elements in OVAL XML instances are assigned a unique identifier based
2619 on the specific elements identifier syntax. These XML instances are
2620 used by tools that support OVAL to drive collection and evaluation of
2621 endpoint posture. When posture collection is performed, an OVAL
2622 Systems Characteristics XML instance is generated based on the
2623 collected posture attributes. When this collected posture is
2624 evaluated, an OVAL Result XML instance is generated that contains the
2625 results of the evaluation. In most implementations, the collection
2626 and evaluation is performed at the same time.
2628 Many of the elements in the OVAL model (i.e., Test, Object, State,
2629 Item) are abstract, requiring a platform-specific schema
2630 implementation, called a "Component Model" in OVAL. These platform
2631 schema implementations are where platform specific posture attributes
2632 are defined. For each aspect of platform posture a specialized OVAL
2633 Object, which appears in the OVAL Definitions model, provides a
2634 format for expressing what posture attribute data to collect from an
2635 endpoint through the specification of a datatype, operation, and
2636 value(s) on entities that uniquely identify a platform configuration
2637 item. For example, a hive, key, and name is used to identify a
2638 registry key on a Windows endpoint. Each specialized OVAL Object has
2639 a corresponding specialized State, which represents the posture
2640 attributes that can be evaluated, and an Item which represents the
2641 specific posture attributes that can be collected. Additionally, a
2642 specialized Test exists that allows collected Items corresponding to
2643 a CollectedObject to be evaluated against one or more specialized
2644 States of the same posture type.
2646 The OVAL language provides a generalized approach suitable for
2647 posture collection and evaluation. While this approach does provide
2648 for a degree of extensibility, there are some concerns that should be
2649 addressed in order to make OVAL a viable basis for SACM's use. These
2650 concerns include:
2652 o Platform Schema Creation and Maintenance: In OVAL platform schema,
2653 the OVAL data model maintains a tight binding between the Test,
2654 Object, State, and Item elements used to assess an aspect of
2655 endpoint posture. Creating a new platform schema or adding a new
2656 posture aspect to an existing platform schema can be a very labor
2657 intensive process. Doing so often involves researching and
2658 understanding system APIs and can be prone to issues with
2659 inconsistency within and between platforms. To simplify platform
2660 schema creation and maintenance, the model needs to be evolved to
2661 generalize the Test, Object, and State elements, requiring only
2662 the definition of an Item representation.
2664 o Given an XML instance based on the Definitions model, it is not
2665 clear in the specification how incremental collection and
2666 evaluation can occur. Because of this, typically, OVAL
2667 assessments are performed on a periodic basis. The OVAL
2668 specification needs to be enhanced to include specifications for
2669 performing event-based and incremental assessment in addition to
2670 full periodic collection.
2672 o Defining new functions for manipulating variable values is current
2673 handled in the Definitions schema. This requires revision to the
2674 core language to add new functions. The OVAL specification needs
2675 to be evolved to provide for greater extensibility in this area,
2676 allowing extension schema to define new functions.
2678 o The current process for releasing a new version of OVAL, bundle
2679 releases of the core language with release of community recognized
2680 platform schema. The revision processes for the core and platform
2681 schema need to be decoupled. Each platform schema should use some
2682 mechanism to declare which core language version it relies on.
2684 If adopted by SCAM, these issues will need to be addressed as part of
2685 the SCAM engineering work to make OVAL more broadly adoptable as a
2686 general purpose data model for posture collection and evaluation.
2688 E.3.2.1.1.2.2. Applicability to Platform Configuration Item
2689 Identification
2691 Each OVAL Object is identified by a globally unique identifier. This
2692 globally unique identifier could be used by the SACM community to
2693 identify platform-specific configuration items and at the same time
2694 serve as collection guidance. If used in this manner, OVAL Objects
2695 would likely need to undergo changes in order to decouple it from
2696 evaluation guidance and to provide more robust collection
2697 capabilities to support the needs of the SACM community.
2699 E.3.2.2. Configuration Item Identifier
2701 An identifier for a high-level, platform-independent configuration
2702 control. This identification concept is necessary to allow similar
2703 configuration item concepts to be comparable across platforms. For
2704 example, a configuration item might be created for the minimum
2705 password length configuration control, which may then have a number
2706 of different platform-specific configuration settings. Without this
2707 type of identification, it will be difficult to perform evaluation of
2708 expected versus actual state in a platform-neutral way.
2710 High-level configuration items tend to change much less frequently
2711 than the platform-specific configuration items (see Appendix E.3.2.1)
2712 that might be associated with them. To provide for the greatest
2713 amount of sustainability, collections of configuration item
2714 identifiers are best defined by specific communities of interest,
2715 while platform-specific identifiers are best defined by the source
2716 vendor of the platform. Under this model, the primary source vendors
2717 would map their platform-specific configuration controls to the
2718 appropriate platform-independent item allowing end-user organizations
2719 to make use of these relationships.
2721 To support different communities of interest, it may be necessary to
2722 support multiple methods for identification of configuration items
2723 and for associating related metadata. Use of an IANA registry
2724 supporting multiple configuration item identification methods would
2725 be an ideal way forward. To the extent possible, a few number of
2726 configuration item identification approaches is desirable, to
2727 maximize the update by vendors who would be maintain mapping of
2728 platform-specific configuration identifiers to the more general
2729 platform-neutral configuration identifiers.
2731 E.3.2.2.1. Related Work
2733 E.3.2.2.1.1. Control Correlation Identifier
2735 The Control Correlation Identifier (CCI) [CCI] is developed and
2736 managed by the United States Department of Defense (US-DoD) Defense
2737 Information Systems Agency (DISA). According to their website, CCI
2738 "provides a standard identifier and description for each of the
2739 singular, actionable statements that comprise an information
2740 assurance (IA) control or IA best practice. CCI bridges the gap
2741 between high-level policy expressions and low-level technical
2742 implementations. CCI allows a security requirement that is expressed
2743 in a high-level policy framework to be decomposed and explicitly
2744 associated with the low-level security setting(s) that must be
2745 assessed to determine compliance with the objectives of that specific
2746 security control. This ability to trace security requirements from
2747 their origin (e.g., regulations, IA frameworks) to their low-level
2748 implementation allows organizations to readily demonstrate compliance
2749 to multiple IA compliance frameworks. CCI also provides a means to
2750 objectively roll-up and compare related compliance assessment results
2751 across disparate technologies."
2753 It is recommended that this approach be analysed as a potential
2754 candidate for use as a configuration item identifier method.
2756 Note: This reference to CCI is for informational purposes. Since the
2757 editors do not represent DISA's interests, its inclusion in this
2758 document does not indicate the presence or lack of desire to
2759 contribute aspects of this effort to SACM.
2761 E.3.2.2.1.2. A Potential Alternate Approach
2763 There will likely be a desire by different communities to create
2764 different collections of configuration item identifiers. This
2765 fracturing may be caused by:
2767 o Different requirements for levels of abstraction,
2769 o Varying needs for timely maintenance of the collection, and
2770 o Differing scopes of technological needs.
2772 Due to these and other potential needs, it will be difficult to
2773 standardize around a single collection of configuration identifiers.
2774 A workable solution will be one that is scalable and usable for a
2775 broad population of end-user organizations. An alternate approach
2776 that should be considered is the definition of data model that
2777 contains a common set of metadata attributes, perhaps supported by an
2778 extensible taxonomy, that can be assigned to platform-specific
2779 configuration items. If defined at a necessary level of granularity,
2780 it may be possible to query collections of platform-specific
2781 configuration items provided by vendors to create groupings at
2782 various levels of abstractions. By utilizing data provided by
2783 vendors, technological needs and the timeliness of information can be
2784 addressed based on customer requirements.
2786 SACM should consider this and other approaches to satisfy the need
2787 for configuration item roll-up in a way that provides the broadest
2788 benefit, while achieving a sensible degree of scalability and
2789 sustainability.
2791 E.3.2.3. Vulnerability Identifier
2793 An unique name for a known software flaw that exists in specific
2794 versions of one or more units of software. One use of a
2795 vulnerability identifier in the SACM context is to associate a given
2796 flaw with the vulnerable software using software identifiers. For
2797 this reason at minimum, software identifiers should identify a
2798 software product to the patch or version level, and not just to the
2799 level that the product is licensed.
2801 E.3.2.3.1. Related Work
2803 E.3.2.3.1.1. Common Vulnerabilities and Exposures
2805 Common Vulnerabilities and Exposures (CVE) [CVE-WEBSITE] is a MITRE
2806 led effort to assign common identifiers to publicly known security
2807 vulnerabilities in software to facilitate the sharing of information
2808 related to the vulnerabilities. CVE is the industry standard by
2809 which software vendors, tools, and security professionals identify
2810 vulnerabilities and could be used to address SACM's need for a
2811 vulnerability identifier.
2813 E.3.3. Endpoint characterization
2815 Target when policies (collection, evaluated, guidance) apply
2817 Collection can be used to further characterize
2818 Also human input
2820 Information required to characterize an endpoint is used to determine
2821 what endpoints are the target of a posture assessment. It is also
2822 used to determine the collection, evaluation, and/or reporting
2823 policies and the associated guidance that apply to the assessment.
2824 Endpoint characterization information may be populated by:
2826 o A manual input process and entered into records associated with
2827 the endpoint, or
2829 o Using information collected and evaluated by an assessment.
2831 Regardless of the method of collection, it will be necessary to query
2832 and exchange endpoint characterization information as part of the
2833 assessment planning workflow.
2835 E.3.3.1. Related Work
2837 E.3.3.1.1. Extensible Configuration Checklist Description Format
2839 E.3.3.1.1.1. Background
2841 The Extensible Configuration Checklist Description Format (XCCDF) is
2842 a specification that provides an XML-based format for expressing
2843 security checklists. The XCCDF 1.2 specification is published by
2844 International Organization for Standardization (ISO) [ISO.18180].
2845 XCCDF contains multiple components and capabilities, and various
2846 components align with different elements of this information model.
2848 This specification was originally published by NIST [NISTIR-7275].
2849 When contributed to ISO Joint Technical Committee 1 (JTC 1), a
2850 comment was introduced indicating an interest in the IETF becoming
2851 the maintenance organization for this standard. If the SACM working
2852 group is interested in taking on engineering work pertaining to
2853 XCCDF, a contribution through a national body can be made to create a
2854 ballot resolution for transition of this standard to the IETF for
2855 maintenance.
2857 E.3.3.1.1.2. Applicability to Endpoint characterization
2859 The target component of XCCDF provides a mechanism for capturing
2860 characteristics about an endpoint including the fully qualified
2861 domain name, network address, references to external identification
2862 information (e.g. Asset Identification), and is extensible to
2863 support other useful information (e.g. MAC address, globally unique
2864 identifier, certificate, etc.). XCCDF may serve as a good starting
2865 point for understanding the types of information that should be used
2866 to identify an endpoint.
2868 E.3.3.1.2. Asset Reporting Format
2870 E.3.3.1.2.1. Background
2872 The Asset Reporting Format (ARF) [NISTIR-7694] is a data model to
2873 express information about assets, and the relationships between
2874 assets and reports. It facilitates the reporting, correlating, and
2875 fusing of asset information within and between organizations. ARF is
2876 vendor and technology neutral, flexible, and suited for a wide
2877 variety of reporting applications.
2879 There are four major sub-components of ARF:
2881 o Asset: The asset component element includes asset identification
2882 information for one or more assets. It simply houses assets
2883 independent of their relationships to reports. The relationship
2884 section can then link the report section to specific assets.
2886 o Report: The report component element contains one or more asset
2887 reports. An asset report is composed of content (or a link to
2888 content) about one or more assets.
2890 o Report-Request: The report-request component element contains the
2891 asset report requests, which can give context to asset reports
2892 captured in the report section. The report-request section simply
2893 houses asset report requests independent of the report which was
2894 subsequently generated.
2896 o Relationship: The relationship component element links assets,
2897 reports, and report requests together with well-defined
2898 relationships. Each relationship is defined as {subject}
2899 {predicate} {object}, where {subject} is the asset, report
2900 request, or report of interest, {predicate} is the relationship
2901 type being established, and {object} is one or more assets, report
2902 requests, or reports.
2904 E.3.3.1.2.2. Relationship to Endpoint Characterization
2906 For Endpoint Characterization, ARF can be used in multiple ways due
2907 to its flexibility. ARF supports the use of the Asset Identification
2908 specification (more in Appendix E.3.3.1.2.3) to embed the
2909 representation of one or more assets as well as relationships between
2910 those assets. It also allows the inclusion of report-requests, which
2911 can provide details on what data was required for an assessment.
2913 ARF is agnostic to the data formats of the collected posture
2914 attributes and therefore can be used within the SACM Architecture to
2915 provide Endpoint Characterization without dictating data formats for
2916 the encoding of posture attributes. The embedded Asset
2917 Identification data model (see Appendix E.3.1.1.1) can be used to
2918 characterize one or more endpoints to allow targeting for collection,
2919 evaluation, etc. Additionally, the report-request model can dictate
2920 the type of reporting that has been requested, thereby providing
2921 context as to which endpoints the guidance applies.
2923 E.3.3.1.2.3. Asset Identification
2925 Described earlier
2927 In the context of Endpoint Characterization, the Asset Identification
2928 data model could be used to encode information that identifies
2929 specific endpoints and/or classes of endpoints to which a particular
2930 assessment is relevant. The flexibility in the Asset Identification
2931 specification allows usage of various endpoint identifiers as defined
2932 by the SACM engineering work.
2934 As stated in Appendix E.3.3.1.2.3, the Asset Identification
2935 specification is included within the Asset Reporting Framework (ARF)
2936 and therefore can be used in concert with that specification as well.
2938 E.3.3.1.3. The CPE Applicability Language
2940 CPE described earlier
2942 Applicability in CPE is defined as an XML language [NISTIR-7698] for
2943 using CPE names to create applicability statements using logical
2944 expressions. These expressions can be used to applicability
2945 statements that can drive decisions about assets, whether or not to
2946 do things like collect data, report data, and execute policy
2947 compliance checks.
2949 It is recommended that SACM evolve the CPE Applicability Language
2950 through engineering work to allow it to better fit into the security
2951 automation vision laid out by the Use Cases and Architecture for
2952 SACM. This should include de-coupling the identification part of the
2953 language from the logical expressions, making it such that the
2954 language is agnostic to the method by which assets are identified.
2955 This will allow use of SWID, CPE Names, or other identifiers to be
2956 used, perhaps supported by an IANA registry of identifier types.
2958 The other key aspect that should be evolved is the ability to make
2959 use of the Applicability Language against a centralized repository of
2960 collected posture attributes. The language should be able to make
2961 applicability statements against previously collected posture
2962 attributes, such that an enterprise can quickly query the correct set
2963 of applicable endpoints in an automated and scalable manner.
2965 E.3.4. Posture Attribute Expression
2967 Discuss the catalog concept. Listing of things that can be chosen
2968 from. Things we can know about. Vendors define catalogs. Ways for
2969 users to get vendor-provided catalogs.
2971 To support the collection of posture attributes, there needs to be a
2972 way for operators to identify and select from a set of platform-
2973 specific attribute(s) to collect. The same identified attributes
2974 will also need to be identified post-collection to associate the
2975 actual value of that attribute pertaining to an endpoint as it was
2976 configured at the time of the collection. To provide for
2977 extensibility, the need exists to support a variety of possible
2978 identification approaches. It is also necessary to enable vendors of
2979 software to provide a listing, or catalog, of the available posture
2980 attributes to operators that can be collected. Ideally, a federated
2981 approach will be used to allow organizations to identify the location
2982 for a repository containing catalogs of posture attributes provided
2983 by authoritative primary source vendors. By querying these
2984 repositories, operators will be able to acquire the appropriate
2985 listings of available posture attributes for their deployed assets.
2986 One or more posture attribute expressions are needed to support these
2987 exchanges.
2989 E.3.4.1. Related Work
2991 The ATOM Syndication Format [RFC4287] provides an extensible,
2992 flexible XML-based expression for organizing a collection of data
2993 feeds consisting of entries. This standard can be used to express
2994 one or more catalogs of posture attributes represented as data feeds.
2995 Groupings of posture attributes would be represented as entries.
2996 These entries could be defined using the data models described in the
2997 "Related Work" sections below. Additionally, this approach can also
2998 be used more generally for guidance repositories allowing other forms
2999 of security automation guidance to be exchanged using the same
3000 format.
3002 E.3.4.2. Platform Configuration Attributes
3004 A low-level, platform-dependent posture attribute as determined by
3005 the authoritative primary source vendor. Collection guidance will be
3006 derived from catalogs of platform specific posture attributes.
3008 For example, a primary source vendor would create a platform-specific
3009 posture attribute that best models the posture attribute data for
3010 their platform.
3012 E.3.4.2.1. Related Work
3014 E.3.4.2.1.1. Open Vulnerability and Assessment Language
3016 A general overview of OVAL was provided previously in
3017 Appendix E.3.2.1.1.2.1. The OVAL System Characteristics platform
3018 extension models provide a catalog of the posture attributes that can
3019 be collected from an endpoint. In OVAL these posture attributes are
3020 further grouped into logical constructs called OVAL Items. For
3021 example, the passwordpolicy_item that is part of the Windows platform
3022 extension groups together all the posture attributes related to
3023 passwords for an endpoint running Windows (e.g. maximum password age,
3024 minimum password length, password complexity, etc.). The various
3025 OVAL Items defined in the OVAL System Characteristics may serve as a
3026 good starting for the types of posture attribute data that needs to
3027 be collected from endpoints.
3029 OVAL platform extension models may be shared using the ATOM
3030 Syndication Format.
3032 E.3.4.2.1.2. Network Configuration Protocol and YANG Data Modeling
3033 Language
3035 The Network Configuration Protocol (NETCONF) [RFC6241] defines a
3036 mechanism for managing and retrieving posture attribute data from
3037 network infrastructure endpoints. The posture attribute data that
3038 can be collected from a network infrastructure endpoint is highly
3039 extensible and can defined using the YANG modeling language
3040 [RFC6020]. Models exist for common datatypes, interfaces, and
3041 routing subsystem information among other subjects. The YANG
3042 modeling language may be useful in providing an extensible framework
3043 for the SACM community to define one or more catalogs of posture
3044 attribute data that can be collected from network infrastructure
3045 endpoints.
3047 Custom YANG modules may also be shared using the ATOM Syndication
3048 Format.
3050 E.3.4.2.1.3. Simple Network Management Protocol and Management
3051 Information Base Entry
3053 The Simple Network Protocol (SNMP) [RFC3411] defines a protocol for
3054 managing and retrieving posture attribute data from endpoints on a
3055 network . The posture attribute data that can be collected of an
3056 endpoint and retrieved by SNMP is defined by the Management
3057 Information Base (MIB) [RFC3418] which is hierarchical collection of
3058 information that is referenced using Object Identifiers . Given this,
3059 MIBs may provide an extensible way for the SACM community to define a
3060 catalog of posture attribute data that can be collected off of
3061 endpoints using SNMP.
3063 MIBs may be shared using the ATOM Syndication Format.
3065 E.3.5. Actual Value Representation
3067 Discuss instance concept.
3069 The actual value of a posture attribute is collected or published
3070 from an endpoint. The identifiers discussed previously provide names
3071 for the posture attributes (i.e., software or configuration item)
3072 that can be the subject of an assessment. The information items
3073 listed below are the actual values collected during the assessment
3074 and are all associated with a specific endpoint.
3076 E.3.5.1. Software Inventory
3078 A software inventory is a list of software identifiers (or content)
3079 associated with a specific endpoint. Software inventories are
3080 maintained in some organized fashion so that entities can interact
3081 with it. Just having software publish identifiers onto an endpoint
3082 is not enough, there needs to be an organized listing of all those
3083 identifiers associated with that endpoint.
3085 E.3.5.1.1. Related Work
3087 E.3.5.1.1.1. Asset Summary Reporting
3089 The Asset Summary Reporting (ASR) specification [NISTIR-7848]
3090 provides a format for capturing summary information about one or more
3091 assets. Specifically, it provides the ability to express a
3092 collection of records from some defined data source and map them to
3093 some set of assets. As a result, this specification may be useful
3094 for capturing the software installed on an endpoint, its relevant
3095 attributes, and associating it with a particular endpoint.
3097 E.3.5.1.1.2. Software Identification Tags
3099 SWID tag were previously introduced in Appendix E.3.1.3.1.2. As
3100 stated before, SWID tags are ideally deployed to an endpoint during
3101 software installation. In the less ideal case, they may also be
3102 generated based on information retrieved from a proprietary software
3103 installation data store. At minimum, SWID tag must contain an
3104 identifier for each unit of installed software. Given this, SWID
3105 tags may be a viable way for SACM to express detailed information
3106 about the software installed on an endpoint.
3108 E.3.5.2. Collected Platform Configuration Posture Attributes
3110 Configurations associated with a software instance associated with an
3111 endpoint
3113 A list of the configuration posture attributes associated with the
3114 actual values collected from the endpoint during the assessment as
3115 required/expressed by any related guidance. Additionally, each
3116 configuration posture attribute is associated with the installed
3117 software instance it pertains to.
3119 E.3.5.2.1. Related Work
3121 E.3.5.2.1.1. Open Vulnerability and Assessment Language
3123 A general overview of OVAL was provided previously in
3124 Appendix E.3.2.1.1.2.1. As mentioned earlier, the OVAL System
3125 Characteristics platform extensions provide a catalog of the posture
3126 attributes that can be collected and assessed in the form of OVAL
3127 Items. These OVAL Items also serve as a model for representing
3128 posture attribute data and associated values that are collected off
3129 an endpoint. Furthermore, the OVAL System Characteristics model
3130 provides a system_info construct that captures information that
3131 identifies and characterizes the endpoint from which the posture
3132 attribute data was collected. Specifically, it includes operating
3133 system name, operating system version, endpoint architecture,
3134 hostname, network interfaces, and an extensible construct to support
3135 arbitrary additional information that may be useful in identifying
3136 the endpoint in an enterprise such as information capture in Asset
3137 Identification constructs. The OVAL System Characteristics model
3138 could serve as a useful starting point for representing posture
3139 attribute data collected from an endpoint although it may need to
3140 undergo some changes to satisfy the needs of the SACM community.
3142 E.3.5.2.1.2. NETCONF-Based Collection
3144 Introduced earlier in Appendix E.3.4.2.1.2, NETCONF defines a
3145 protocol for managing and retrieving posture attribute data from
3146 network infrastructure endpoints. NETCONF provides the
3147 and operations to retrieve the configuration data, and
3148 configuration data and state data respectively from a network
3149 infrastructure endpoint. Upon successful completion of these
3150 operations, the current posture attribute data of the network
3151 infrastructure endpoint will be made available. NETCONF also
3152 provides a variety of filtering mechanisms (XPath, subtree, content
3153 matching, etc.) to trim down the posture attribute data that is
3154 collected from the endpoint. Given that NETCONF is widely adopted by
3155 network infrastructure vendors, it may useful to consider this
3156 protocol as a standardized mechanism for collecting posture attribute
3157 data from network infrastructure endpoints.
3159 As a side note, members of the OVAL Community have also developed a
3160 proposal to extend the OVAL Language to support the assessment of
3161 NETCONF configuration data [1]. The proposal leverages XPath to
3162 extract the posture attribute data of interest from the XML data
3163 returned by NETCONF. The collected posture attribute data can then
3164 be evaluated using OVAL Definitions and the results of the evaluation
3165 can be expressed as OVAL Results. While this proposal is not
3166 currently part of the OVAL Language, it may be worth considering.
3168 E.3.5.2.1.3. SNMP-Based Collection
3170 The SNMP, previously introduced in Appendix E.3.4.2.1.3, defines a
3171 protocol for managing and retrieving posture attribute data from
3172 endpoints on a network [RFC3411]. SNMP provides three protocol
3173 operations [RFC3416] (GetRequest, GetNextRequest, and GetBulkRequest)
3174 for retrieving posture attribute data defined by MIB objects. Upon
3175 successful completion of these operations, the requested posture
3176 attribute data of the endpoint will be made available to the
3177 requesting application. Given that SNMP is widely adopted by
3178 vendors, and the MIBs that define posture attribute data on an
3179 endpoint are highly extensible, it may useful to consider this
3180 protocol as a standardized mechanism for collecting posture attribute
3181 data from endpoints in an enterprise.
3183 E.3.6. Evaluation Guidance
3185 E.3.6.1. Configuration Evaluation Guidance
3187 The evaluation guidance is applied by evaluators during posture
3188 assessment of an endpoint. This guidance must be able to reference
3189 or be associated with the following previously defined information
3190 elements:
3192 o configuration item identifiers,
3194 o platform configuration identifiers, and
3196 o collected Platform Configuration Posture Attributes.
3198 E.3.6.1.1. Related Work
3200 E.3.6.1.1.1. Open Vulnerability and Assessment Language
3202 A general overview of OVAL was provided previously in
3203 Appendix E.3.2.1.1.2.1. The OVAL Definitions model provides an
3204 extensible framework for making assertions about the state of posture
3205 attribute data collected from an endpoint. Guidance written against
3206 this model consists of one or more OVAL Tests, that can be logically
3207 combined, where each OVAL Test defines what posture attributes should
3208 be collected from an endpoint (as OVAL Objects) and optionally
3209 defines the expected state of the posture attributes (as OVAL
3210 States). While the OVAL Definitions model may be a useful starting
3211 point for evaluation guidance, it will likely require some changes to
3212 decouple collection and evaluation concepts to satisfy the needs of
3213 the SACM community.
3215 E.3.6.1.1.2. XCCDF Rule
3217 A general description of XCCDF was provided in Appendix E.3.3.1.1.1.
3218 As noted there, an XCCDF document represents a checklist of items
3219 against which a given endpoint's state is compared and evaluated. An
3220 XCCDF Rule represents one assessed item in this checklist. A Rule
3221 contains both a prose description of the assessed item (either for
3222 presentation to the user in a tool's user interface, or for rendering
3223 into a prose checklist for human consumption) and can also contain
3224 instructions to support automated evaluation of the assessed item, if
3225 such automated assessment is possible. Automated assessment
3226 instructions can be provided either within the XCCDF Rule itself, or
3227 by providing a reference to instructions expressed in other
3228 languages, such as OVAL.
3230 In order to support greater flexibility in XCCDF, checklists can be
3231 tailored to meet certain needs. One way to do this is to enable or
3232 disable certain rules that are appropriate or inappropriate to a
3233 given endpoint, respectively. For example, a single XCCDF checklist
3234 might contain check items to evaluate the configuration of an
3235 endpoint's operating system. An endpoint deployed in an enterprise's
3236 DMZ might need to be locked down more than a common internal
3237 endpoint, due to the greater exposure to attack. In this case, some
3238 operating system configuration requirements for the DMZ endpoint
3239 might be unnecessary for the internal endpoint. Nonetheless, most
3240 configuration requirements would probably remain applicable to both
3241 environments (providing a common baseline for configuration of the
3242 given operating system) and thus be common to the checking
3243 instructions for both types of endpoints. XCCDF supports this by
3244 allowing a single checklist to be defined, but then tailored to the
3245 needs of the assessed endpoint. In the previous example, some Rules
3246 that apply only to the DMZ endpoint would be disabled during the
3247 assessment of an internal endpoint and would not be exercised during
3248 the assessment or count towards the assessment results. To
3249 accomplish this, XCCDF uses the CPE Applicability Language. By
3250 enhancing this applicability language to support other aspects of
3251 endpoint characterization (see Appendix E.3.3.1.3), XCCDF will also
3252 benefit from these enhancements.
3254 In addition, XCCDF Rules also support parameterization, allowing
3255 customization of the expected value for a given check item. For
3256 example, the DMZ endpoint might require a password of at least 12
3257 characters, while an internal endpoint may only need 8 or more
3258 characters in its password. By employing parameterization of the
3259 XCCDF Rule, the same Rule can be used when assessing either type of
3260 endpoint, and simply be provided with a different target parameter
3261 each time to reflect the different role-based requirements. Sets of
3262 customizations can be stored within the XCCDF document itself: XCCDF
3263 Values store parameters values that can be used in tailoring, while
3264 XCCDF Profiles store sets of tailoring instructions, including
3265 selection of certain Values as parameters and the enabling and
3266 disabling of certain Rules. The tailoring capabilities supported by
3267 XCCDF allow a single XCCDF document to encapsulate configuration
3268 evaluation guidance that applies to a broad range of endpoint roles.
3270 E.3.7. Evaluation Result Reporting
3272 E.3.7.1. Configuration Evaluation Results
3274 The evaluation guidance applied during posture assessment of an
3275 endpoint to customize the behavior of evaluators. Guidance can be
3276 used to define specific result output formats or to select the level-
3277 of-detail for the generated results. This guidance must be able to
3278 reference or be associated with the following previously defined
3279 information elements:
3281 o configuration item identifiers,
3283 o platform configuration identifiers, and
3285 o collected Platform Configuration Posture Attributes.
3287 E.3.7.1.1. Related Work
3289 E.3.7.1.1.1. XCCDF TestResults
3291 A general description of the eXtensible Configuration Checklist
3292 Description Format (XCCDF) was provided in section
3293 Appendix E.3.3.1.1.1. The XCCDF TestResult structure captures the
3294 outcome of assessing a single endpoint against the assessed items
3295 (i.e., XCCDF Rules) contained in an XCCDF instance document. XCCDF
3296 TestResults capture a number of important pieces of information about
3297 the assessment including:
3299 o The identity of the assessed endpoint. See Appendix E.3.3.1.1.2
3300 for more about XCCDF structures used for endpoint identification.
3302 o Any tailoring of the checklist that might have been employed. See
3303 Appendix E.3.6.1.1.2 for more on how XCCDF supports tailoring.
3305 o The individual results of the assessment of each enabled XCCDF
3306 Rule in the checklist. See Appendix E.3.6.1.1.2 for more on XCCDF
3307 Rules.
3309 The individual results for a given XCCDF Rule capture only whether
3310 the rule "passed", "failed", or experienced some exceptional
3311 condition, such as if an error was encountered during assessment.
3312 XCCDF 1.2 Rule results do not capture the actual state of the
3313 endpoint. For example, an XCCDF Rule result might indicate that an
3314 endpoint failed to pass requirement that passwords be of a length
3315 greater than or equal to 8, but it would not capture that the
3316 endpoint was, in fact, only requiring passwords of 4 or more
3317 characters. It may, however, be possible for a user to discover this
3318 information via other means. For example, if the XCCDF Rule uses an
3319 OVAL Definition to effect the Rule's evaluation, then the actual
3320 endpoint state may be captured in the corresponding OVAL System
3321 Characteristics file.
3323 The XCCDF TestResult structure does provide a useful structure for
3324 understanding the overall assessment that was conducted and the
3325 results thereof. The ability to quickly determine the Rules that are
3326 not complied with on a given endpoint allow administrators to quickly
3327 identify where remediation needs to occur.
3329 E.3.7.1.1.2. Open Vulnerability and Assessment Language
3331 A general overview of OVAL was provided previously in
3332 Appendix E.3.2.1.1.2.1. OVAL Results provides a model for expressing
3333 the results of the assessment of the actual state of the posture
3334 attribute values collected of an endpoint (represented as an OVAL
3335 System Characteristics document) against the expected posture
3336 attribute values (defined in an OVAL Definitions document. Using
3337 OVAL Directives, the granularity of OVAL Results can also be
3338 specified. The OVAL Results model may be useful in providing a
3339 format for capturing the results of an assessment.
3341 E.3.7.1.1.3. Asset Summary Reporting
3343 A general overview of ASR was provided previously in
3344 Appendix E.3.5.1.1.1. As ASR provides a way to report summary
3345 information about assets, it can be used within the SACM Architecture
3346 to provide a way to aggregate asset information for later use. It
3347 makes no assertions about the data formats used by the assessment,
3348 but rather provides an XML, record-based way to collect aggregated
3349 information about assets.
3351 By using ASR to collect this summary information within the SACM
3352 Architecture, one can provide a way to encode the details used by
3353 various reporting requirements, including user-definable reports.
3355 E.3.7.1.1.4. ARF
3357 A general overview of ARF was provided previously in
3358 Appendix E.3.3.1.2.1. Because ARF is data model agnostic, it can
3359 provide a flexible format for exchanging collection and evaluation
3360 information from endpoints. It additionally provides a way to encode
3361 relationships between guidance and assets, and as such, can be used
3362 to associate assessment results with guidance. This could be the
3363 guidance that directly triggered the assessment, or for guidance that
3364 is run against collected posture attributes located in a central
3365 repository.
3367 E.3.7.2. Software Inventory Evaluation Results
3369 The results of an evaluation of an endpoint's software inventory
3370 against an authorized software list. The authorized software list
3371 represents the policy for what software units are allowed,
3372 prohibited, and mandatory for an endpoint.
3374 Authors' Addresses
3376 David Waltermire (editor)
3377 National Institute of Standards and Technology
3378 100 Bureau Drive
3379 Gaithersburg, Maryland 20877
3380 USA
3382 Email: david.waltermire@nist.gov
3383 Kim Watson
3384 United States Department of Homeland Security
3385 DHS/CS&C/FNR
3386 245 Murray Ln. SW, Bldg 410
3387 MS0613
3388 Washington, DC 20528
3389 USA
3391 Email: kimberly.watson@hq.dhs.gov
3393 Clifford Kahn
3394 Juniper Networks, Inc.
3395 10 Technology Park Drive
3396 Westford, MA 01886
3397 USA
3399 Email: cliffordk@juniper.net
3401 Lisa Lorenzin
3402 Juniper Networks, Inc.
3403 3614 Laurel Creek Way
3404 Durham, NC 27712
3405 USA
3407 Email: llorenzin@juniper.net