idnits 2.17.1
draft-ietf-sacm-vuln-scenario-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 9, 2016) is 2757 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-03) exists of
draft-coffin-sacm-nea-swid-patnc-01
== Outdated reference: A later version (-18) exists of
draft-ietf-sacm-requirements-13
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SACM C. Coffin
3 Internet-Draft B. Cheikes
4 Intended status: Informational C. Schmidt
5 Expires: March 13, 2017 D. Haynes
6 The MITRE Corporation
7 J. Fitzgerald-McKay
8 Department of Defense
9 D. Waltermire
10 National Institute of Standards and Technology
11 September 9, 2016
13 SACM Vulnerability Assessment Scenario
14 draft-ietf-sacm-vuln-scenario-02
16 Abstract
18 This document describes an automated enterprise vulnerability
19 assessment scenario aligned with the SACM Use Cases. The scenario
20 assumes the existence of endpoint management capabilities and begins
21 with an enterprise ingesting vulnerability description information.
22 Endpoints are assessed against the vulnerability description
23 information based on a combination of examining known endpoint
24 characterization information and collected endpoint information.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on March 13, 2017.
43 Copyright Notice
45 Copyright (c) 2016 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 4. Vulnerability Assessment Pre-requisites . . . . . . . . . . . 4
64 4.1. Endpoint Management Capabilities . . . . . . . . . . . . 5
65 4.2. Vulnerability Description Information . . . . . . . . . . 5
66 5. Endpoint Vulnerability Assessment Capabilities . . . . . . . 5
67 6. Vulnerability Assessment Results . . . . . . . . . . . . . . 7
68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
70 9. Informative References . . . . . . . . . . . . . . . . . . . 7
71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8
72 A.1. Changes in Revision -02 . . . . . . . . . . . . . . . . . 8
73 A.2. Changes in Revision -01 . . . . . . . . . . . . . . . . . 9
74 A.3. Changes Since Adopted as a WG I-D -00 . . . . . . . . . . 9
75 A.4. Changes in Revision draft-coffin-sacm-vuln-scenario-01 . 10
76 Appendix B. Implementation Examples . . . . . . . . . . . . . . 11
77 B.1. Endpoint Data Collection . . . . . . . . . . . . . . . . 11
78 B.2. Vulnerability Description Information . . . . . . . . . . 12
79 B.3. Secondary Assessment . . . . . . . . . . . . . . . . . . 12
80 B.4. Assessment Results . . . . . . . . . . . . . . . . . . . 13
81 Appendix C. Priority . . . . . . . . . . . . . . . . . . . . . . 13
82 Appendix D. SACM Usage Scenarios . . . . . . . . . . . . . . . . 14
83 Appendix E. SACM Requirements and Charter - Future Work . . . . 16
84 Appendix F. SACM Use Case Alignment . . . . . . . . . . . . . . 16
85 F.1. Endpoint Identification . . . . . . . . . . . . . . . . . 16
86 F.2. Endpoint Data Collection . . . . . . . . . . . . . . . . 16
87 F.3. Vulnerability Description Information . . . . . . . . . . 17
88 F.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 17
89 F.5. Secondary Assessment . . . . . . . . . . . . . . . . . . 17
90 F.6. Assessment Results . . . . . . . . . . . . . . . . . . . 18
91 Appendix G. Alignment with Other Existing Works . . . . . . . . 18
92 G.1. Critical Security Controls . . . . . . . . . . . . . . . 18
93 G.1.1. Continuous Vulnerability Assessment . . . . . . . . . 18
94 G.1.2. Hardware and Software Inventories . . . . . . . . . . 19
95 Appendix H. Continuous Vulnerability Assessment . . . . . . . . 20
96 Appendix I. Data Attribute Table . . . . . . . . . . . . . . . . 20
97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
99 1. Introduction
101 This document describes a detailed, enterprise-specific vulnerability
102 assessment scenario from which information model elements can be
103 discovered. This scenario also informs protocol and data model
104 development in support of vulnerability assessment, as part of
105 overall posture assessment (see Appendix B for examples of solutions
106 that support this scenario).
108 Vulnerability discovery, disclosure, publication, and prioritization
109 is out of scope. However, given the importance of prioritization in
110 an enterprise's vulnerability assessment process, it is discussed in
111 Appendix C.
113 Information on how the scenario aligns with SACM and other existing
114 work is discussed in Appendix D through Appendix G.
116 2. Terminology
118 Vulnerability description information: Information pertaining to the
119 existence of a flaw or flaws in software, hardware, and/or
120 firmware, which could potentially have an adverse impact on
121 enterprise IT functionality and/or security. Vulnerability
122 description information should contain enough information to
123 support vulnerability detection.
125 Vulnerability detection data: A type of guidance extracted or
126 derived from vulnerability description information that
127 describes the specific mechanisms of vulnerability detection
128 that is used by an enterprise's vulnerability management
129 capabilities to determine if a vulnerability is present on an
130 endpoint.
132 Endpoint management capabilities: An enterprise IT department's
133 ability to manage endpoint identity, endpoint information, and
134 associated metadata on an ongoing basis.
136 Vulnerability management capabilities: An enterprise IT department's
137 ability to manage endpoint vulnerabilities and associated
138 metadata on an ongoing basis by ingesting vulnerability
139 description information and vulnerability detection data, and
140 performing vulnerability assessments.
142 Vulnerability assessment capabilities: An enterprise IT department's
143 ability to determine whether a set of endpoints is vulnerable
144 according to the information contained in the vulnerability
145 description information.
147 3. Assumptions
149 A number of assumptions must be stated in order to further clarify
150 the position and scope of this document.
152 The document assumes that:
154 o The enterprise has received vulnerability description information,
155 and that the information has already been processed into
156 vulnerability detection data that the enterprise's security
157 software tools can understand and use.
159 o The enterprise has a means of identifying enterprise endpoints
160 through the execution of Target Endpoint Discovery Tasks although
161 assertions about some details of this capability are made.
163 o The enterprise has a means of extracting relevant information
164 about enterprise endpoints in a form that is compatible with the
165 vulnerability description data.
167 o All information described in this scenario is available in the
168 vulnerability description data and serves as the basis of
169 assessments.
171 o The enterprise can provide all relevant information about any
172 endpoint needed to perform the described assessment.
174 o The enterprise has a mechanism for long-term storage of
175 vulnerability description information, vulnerability detection
176 data, and vulnerability assessment results.
178 o The enterprise has a procedure for reassessment of endpoints at
179 some point after initial assessment (see Appendix H for more
180 information).
182 4. Vulnerability Assessment Pre-requisites
184 In order to successfully support the vulnerability assessment
185 scenario, an enterprise needs to have the following capabilities
186 deployed on their network and information readily available.
188 4.1. Endpoint Management Capabilities
190 Endpoint management capabilities are assumed to be in place within
191 the enterprise, and are expected to collect a minimum set of
192 attributes from the endpoints under management via Collection Tasks
193 and to establish an endpoint's identity within the scope of that
194 domain. Endpoint identity can be established by collecting certain
195 identifying attributes, collectively known as the Target Endpoint
196 Identifier, that allow for unique and persistent tracking of
197 endpoints on the enterprise network. Examples include, but are not
198 limited to, IP address, MAC address, Fully Qualified Domain Names
199 (FQDNs), pre-provisioned identifiers such as Globally Unique
200 Identifiers (GUIDs) or copies of serial numbers, certificates,
201 hardware identity values, or similar attributes. To simplify the
202 identification of an endpoint, a Target Endpoint Label may be created
203 and assigned to refer to the Target Endpoint Identifier. All of the
204 information collected by the endpoint management capabilities is
205 stored, with appropriate metadata (i.e. timestamp), in a central
206 location and used to build up a Target Endpoint Characterization
207 Record and Target Endpoint Profile via a Target Endpoint
208 Characterization Task. The endpoint management capabilities are
209 expected to be performed on an ongoing basis, resulting in routine,
210 or even event-driven, collection of basic endpoint information.
212 See Appendix I for information-specific details.
214 4.2. Vulnerability Description Information
216 Vulnerability description information is expected to be periodically
217 received by the enterprise. Upon receipt, the vulnerability
218 description information is expected to be assigned a unique tracking
219 identifier, stored in a repository (with appropriate metadata) in raw
220 form, and transformed into a machine-readable vulnerability detection
221 data with unique tracking identifier understood by the components
222 described by this scenario. This transformed form can be referred to
223 as the vulnerability detection data. At some point, receipt and
224 processing of vulnerability description data is expected to trigger
225 the vulnerability assessment.
227 See Appendix I for information-specific details.
229 5. Endpoint Vulnerability Assessment Capabilities
231 When new vulnerability description information is received by the
232 enterprise, affected endpoints are identified and assessed. The
233 vulnerability is said to apply to an endpoint if the endpoint
234 satisfies the conditions expressed in the vulnerability detection
235 data.
237 A vulnerability assessment (i.e. vulnerability detection) is
238 performed in two steps:
240 o Endpoint information collected by the endpoint management
241 capabilities is examined by the vulnerability management
242 capabilities through Evaluation Tasks.
244 o If the data possessed by the endpoint management capabilities is
245 insufficient, a Collection Task is triggered and the necessary
246 data is collected from the target endpoint.
248 Vulnerability detection relies on the examination of different
249 endpoint information depending on the nature of a specific
250 vulnerability. Common endpoint information used to detect a
251 vulnerability includes:
253 o A specific software version is installed on the endpoint
255 o File system attributes
257 o Specific state attributes
259 In many cases, the endpoint information needed to determine an
260 endpoint's vulnerability status will have been previously collected
261 by the endpoint management capabilities and available in a
262 Repository. However, in other cases, the necessary endpoint
263 information will not be readily available in a Repository and a
264 Collection Task will be triggered to collect it from the target
265 endpoint. Of course, some implementations of endpoint management
266 capabilities may prefer to enable operators to perform this
267 collection under certain circumstances, even when sufficient
268 information can be provided by the endpoint management capabilities
269 (e.g. there may be freshness requirements for information).
271 The collection of additional endpoint information for the purpose of
272 vulnerability assessment does not necessarily need to be a pull by
273 the vulnerability assessment capabilities. Over time, some new
274 pieces of information that are needed during common types of
275 assessments might be identified. Endpoint management capabilities
276 can be reconfigured to have this information delivered automatically.
277 This avoids the need to trigger additional Collection Tasks to gather
278 this information during assessments, streamlining the assessment
279 process. Likewise, it might be observed that certain information
280 delivered by endpoint management capabilities is rarely used. In
281 this case, it might be useful to re-configure the endpoint management
282 capabilities to no longer collect this information to reduce network
283 and processing overhead. Instead, a new Collection Task can be
284 triggered to gather this data on the rare occasions when it is
285 needed.
287 See Appendix I for information-specific details.
289 6. Vulnerability Assessment Results
291 Vulnerability assessment results present evaluation results along
292 with sufficient context, so that appropriate action can be taken.
293 Vulnerability assessment results are ideally stored for later use.
295 See Appendix I for information-specific details.
297 7. IANA Considerations
299 This memo includes no request to IANA.
301 8. Security Considerations
303 This document provides a core narrative that walks through an
304 automated enterprise vulnerability assessment scenario and is aligned
305 with SACM "Endpoint Security Posture Assessment: Enterprise Use
306 Cases" [RFC7632]. As a result, the security considerations for
307 [RFC7632] apply to this document. Furthermore, the data collected as
308 part of the vulnerability assessment may provide attackers with
309 useful information such as what software an enterprise is running on
310 their endpoints. As a result, organizations should consider properly
311 protecting this information.
313 9. Informative References
315 [charter-ietf-sacm-01]
316 Security Automation and Continuous Monitoring, "Charter,
317 Version 1.0", October 2015,
318 .
320 [critical-controls]
321 Center for Internet Security, "Critical Security Controls,
322 Version 6.0", .
325 [cvrf] Industry Consortium for Advancement of Security on the
326 Internet, "Common Vulnerability and Reporting Framework",
327 May 2012, .
329 [I-D.coffin-sacm-nea-swid-patnc]
330 Coffin, C., Haynes, D., Schmidt, C., and J. Fitzgerald-
331 McKay, "SWID Message and Attributes for PA-TNC", draft-
332 coffin-sacm-nea-swid-patnc-01 (work in progress), June
333 2016.
335 [I-D.cokus-sacm-oval-results-model]
336 Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez,
337 "OVAL(R) Results Model", draft-cokus-sacm-oval-results-
338 model-01 (work in progress), September 2016.
340 [I-D.hansbury-sacm-oval-info-model-mapping]
341 mhansbury@mitre.org, m., Haynes, D., and J. Gonzalez,
342 "OVAL and the SACM Information Model", draft-hansbury-
343 sacm-oval-info-model-mapping-03 (work in progress),
344 September 2016.
346 [I-D.haynes-sacm-oval-definitions-model]
347 Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez,
348 "OVAL(R) Definitions Model", draft-haynes-sacm-oval-
349 definitions-model-01 (work in progress), September 2016.
351 [I-D.ietf-sacm-requirements]
352 Cam-Winget, N. and L. Lorenzin, "Security Automation and
353 Continuous Monitoring (SACM) Requirements", draft-ietf-
354 sacm-requirements-13 (work in progress), March 2016.
356 [I-D.rothenberg-sacm-oval-sys-char-model]
357 Cokus, M., Haynes, D., Rothenberg, D., and J. Gonzalez,
358 "OVAL(R) System Characteristics Model", draft-rothenberg-
359 sacm-oval-sys-char-model-01 (work in progress), September
360 2016.
362 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
363 Posture Assessment: Enterprise Use Cases", RFC 7632,
364 DOI 10.17487/RFC7632, September 2015,
365 .
367 Appendix A. Change Log
369 A.1. Changes in Revision -02
371 Changed "capability" in the context of endpoint management,
372 vulnerability management, and vulnerability assessments to
373 "capabilities" to avoid confusion with the term "capability" in the
374 terminology draft.
376 Made a few other minor editorial and clarification changes.
378 A.2. Changes in Revision -01
380 Clarified how the endpoint management capability can reconfigured
381 over time to adapt to the needs of an enterprise. GitHub issue #12
382 (https://github.com/sacmwg/vulnerability-scenario/issues/12).
384 Included references to the various appendices in the document.
385 GitHub issue #18 (https://github.com/sacmwg/vulnerability-scenario/
386 issues/18).
388 Fixed typos and other minor editorial changes in the document.
389 GitHub issue #19 (https://github.com/sacmwg/vulnerability-scenario/
390 issues/18). GitHub issue #20 (https://github.com/sacmwg/
391 vulnerability-scenario/issues/20). GitHub issue #22
392 (https://github.com/sacmwg/vulnerability-scenario/issues/22).
394 Updated references to the Critical Controls to Version 6.0. GitHub
395 issue #23 (https://github.com/sacmwg/vulnerability-scenario/
396 issues/23).
398 Aligned the scenario with SACM Tasks. GitHub issue #25
399 (https://github.com/sacmwg/vulnerability-scenario/issues/25).
401 A.3. Changes Since Adopted as a WG I-D -00
403 Made various organizational and editorial changes as proposed by Adam
404 Montville. GitHub issue #4 (https://github.com/sacmwg/vulnerability-
405 scenario/issues/4).
407 Removed the TODO from the Security Considerations section
408 (https://github.com/sacmwg/vulnerability-scenario/issues/8).
410 Clarified the definition of "vulnerability detection data" to explain
411 how it was guidance and provided instructions for security tools on
412 how to carry out a vulnerability assessment. GitHub issue #13
413 (https://github.com/sacmwg/vulnerability-scenario/issues/13).
415 Changed "targeted collection" to "supplemental collection". GitHub
416 issue #14 (https://github.com/sacmwg/vulnerability-scenario/
417 issues/14).
419 Clarified that the ability for an enterprise to convert vulnerability
420 description information and process it into a format usable by
421 security tools is the same as the converting vulnerability
422 description information into vulnerability detection data. GitHub
423 issue #15 (https://github.com/sacmwg/vulnerability-scenario/
424 issues/15).
426 Determine if we need to remove references to the long-term storage of
427 data in repositories. GitHub issue #16 (https://github.com/sacmwg/
428 vulnerability-scenario/issues/16).
430 Moved the information needs captured in Appendix D.2 into the
431 Information Model. GitHub issue #17 (https://github.com/sacmwg/
432 vulnerability-scenario/issues/17).
434 A.4. Changes in Revision draft-coffin-sacm-vuln-scenario-01
436 Clarification of the vulnerability description data IDs in sections 4
437 and 6.
439 Added "vulnerability remediation" to the Assessment Results and Data
440 Attribute Table and Definitions sections.
442 Added Implementation Examples to Endpoint Identification and Initial
443 (Pre-Assessment) Data Collection, Vulnerability Description Data,
444 Endpoint Applicability and Assessment, and Assessment Results
445 sections.
447 Added an example to vulnerability description data in the scope
448 section.
450 Added a sentence to clarify vulnerability description data definition
451 in the scope section.
453 Added data repository example for long-term storage scope item.
455 Added sentence to direct reader to examples of basic system
456 information in endpoint identification section.
458 Split the examples of information to collect in the pre-assessment
459 collection section into a basic and advanced list.
461 Added examples of data stored in the repository in the Assessment
462 Results section.
464 Added sentence for human-assigned attributes in the Future Work
465 section.
467 Replaced "vulnerability report" to "vulnerability description data"
468 because the term report was causing confusion. Similarly, replaced
469 "assessment report" with "assessment results".
471 Replaced "Configuration Management Database (CMDB)" with "Repository"
472 which is SACM's term for a data store.
474 Replaced endpoint "Role" with "Purpose" because "Role" is already
475 defined in SACM. Also, removed "Function" because it too is already
476 defined in SACM.
478 Clarified that the document does not try to define a normalized data
479 format for vulnerability description data although it does not
480 preclude the creation of such a format.
482 Included additional examples of software configuration information.
484 Clarified the section around endpoint identification to make it clear
485 designation attributes used to correlate and identify endpoints are
486 both persistent and unique. Furthermore, text was added to explain
487 how the persistency of attributes may vary. This was based on
488 knowledge gained from the Endpoint ID Design Team.
490 Updated the Security Considerations section to mention those
491 described in [RFC7632].
493 Removed text around Bring Your Own Device (BYOD). While important,
494 BYOD just adds complexity to this initial draft. BYOD should be
495 addressed in a later revision.
497 Merged the list of "basic endpoint information" and the list of
498 "human-assigned endpoint attributes" as both represent data we want
499 to collect about an endpoint. Whether or not that data is natively
500 available on the endpoint for collection or assigned by a human,
501 computed, or derived from other data which may or may not be
502 available on the endpoint for collection seems arbitrary. With this
503 scenario, we primarily care about expressing information needs rather
504 than how the information is collected or from where.
506 Appendix B. Implementation Examples
508 B.1. Endpoint Data Collection
510 Within the SACM Architecture, the Internal and External Collector
511 components could be used to allow enterprises to collect posture
512 attributes that demonstrate compliance with enterprise policy.
513 Endpoints can be required to provide posture attributes, which may
514 include identification attributes to enable persistent
515 communications.
517 The SWID Message and Attributes for PA-TNC standard
518 [I-D.coffin-sacm-nea-swid-patnc] defines collection and validation of
519 software identities using the ISO Software Identification Tag
520 Standard. Using this standard, the identity of all installed
521 software including the endpoint operating system, could be collected
522 and used for later assessment.
524 The OVAL Definitions Model [I-D.haynes-sacm-oval-definitions-model]
525 provides a data model that can be used to specify what posture
526 attributes to collect as well as their expected values which can be
527 used to drive an assessment.
529 The OVAL System Characteristics Model
530 [I-D.rothenberg-sacm-oval-sys-char-model] can be used to capture
531 information about an endpoint. The model is specifically suited to
532 expressing OS information, endpoint identification information (such
533 as IP and MAC addresses), and other endpoint metadata.
535 B.2. Vulnerability Description Information
537 The Common Vulnerability Reporting Framework (CVRF) [cvrf] is an XML-
538 based language that attempts to standardize the creation of
539 vulnerability description information. Using CVRF, the enterprise
540 could create automated tools based on the standardized schema which
541 would obtain the needed and relevant information useful for later
542 assessments and assessment results.
544 B.3. Secondary Assessment
546 Within the SACM Architecture, the assessment task would be handled by
547 the Evaluator component. If previously collected data is used, it
548 would be obtained from a Data Store component.
550 Within the SACM Architecture, the Internal and External Collector
551 components could be used to allow enterprises to collect posture
552 attributes that demonstrate compliance with enterprise policy.
553 Endpoints can be required to provide posture attributes, which may
554 include identification attributes to enable persistent
555 communications.
557 The SWID Message and Attributes for PA-TNC standard defines
558 collection and validation of software identities using the ISO
559 Software Identification Tag Standard. Using this standard, all
560 installed software including the endpoint operating system could be
561 collected and stored for later assessment.
563 The OVAL Definitions Model provides a data model that can be used to
564 specify what posture attributes to collect as well as their expected
565 values which can be used to drive an assessment.
567 The OVAL System Characteristics Model can be used to capture
568 information about an endpoint. The model is specifically suited to
569 expressing OS information, endpoint identification information (such
570 as IP and MAC addresses), and other endpoint metadata.
572 The SACM Internal and External Attribute Collector components can be
573 used to allow enterprises to collect posture attributes that
574 demonstrate compliance with enterprise policy. Endpoints can be
575 required to provide posture attributes, which may include
576 identification attributes to enable persistent communications.
578 B.4. Assessment Results
580 The OVAL Results Model [I-D.cokus-sacm-oval-results-model] provides a
581 data model to encode the results of the assessment, which could then
582 be stored in a Repository and later accessed. The assessment results
583 described in this scenario could be stored and later accessed using
584 the OVAL Results Model. Note that the use of the OVAL Results Model
585 for sharing results is not recommended per section 7.3 of the OVAL
586 and the SACM Information Model
587 [I-D.hansbury-sacm-oval-info-model-mapping].
589 Within the SACM Architecture, the generation of the assessment
590 results would occur in the Report Generator component. Those results
591 might then be moved to a Data Store component for later sharing and
592 retrieval as defined by SACM.
594 Appendix C. Priority
596 Priorities associated with the vulnerability description information,
597 assessment results, and any remedy is important, but is treated as a
598 separate challenge and, as such, has not been integrated into the
599 description of this scenario. Nevertheless, it is important to point
600 out and describe the use of priorities in the overall vulnerability
601 assessment scenario as a separate issue with its own sets of
602 requirements.
604 Priority in regard to vulnerability description information, can be
605 viewed in a couple of different ways within an enterprise. The
606 assessment prioritization involves prioritization of the
607 vulnerability description information assessment process. This
608 determines what vulnerability description information is assessed,
609 and in what order it is assessed in. For instance, a vulnerability
610 affecting an operating system or application used throughout the
611 enterprise would likely be prioritized higher than a vulnerability in
612 an application which is used only on a few, low-criticality
613 endpoints.
615 The prioritization of remedies relates to the enterprise remediation
616 and mitigation process based on the discovered vulnerabilities. Once
617 an assessment has been performed and applicable endpoints identified,
618 enterprise vulnerability managers must determine where to focus their
619 efforts to apply appropriate remedies. For example, a vulnerability
620 that is easily exploitable and which can allow arbitrary code
621 execution might be remedied before a vulnerability that is more
622 difficult to exploit or which just degrades performance.
624 Some vulnerability description information include severities and/or
625 other information that places the vulnerability in context. This
626 information can be used in both of the priority types discussed
627 above. In other cases, enterprise administrators may need to
628 prioritize based only on what they know about their enterprise and
629 the description provided in the vulnerability description
630 information.
632 Examples of data attributes specific to priority of assessments and/
633 or remedies include (but not limited to) the following:
635 o Enterprise - defined purpose of the device, criticality of the
636 device, exposure of the device, etc.
638 o Severity attributes - A rating or score that attempts to provide
639 the level of severity or criticality associated with a given
640 vulnerability.
642 o Cyber threat intelligence - information such as tactics,
643 techniques, and procedures of threat actors, indicators of
644 compromise, incidents, courses of action, etc. that help the
645 enterprise understand relevant threats and how to detect,
646 mitigate, or respond to them.
648 Appendix D. SACM Usage Scenarios
650 The SACM "Endpoint Security Posture Assessment: Enterprise Use Cases"
651 document ([RFC7632]) defines multiple usage scenarios that are meant
652 to provide examples of implementing the use cases and building block
653 capabilities. Below is a brief summary of some of these usage
654 scenarios and how this document aligns and/or adds additional value
655 to the identified usage scenarios.
657 o Automated Checklist Verification (2.2.2) - "An enterprise operates
658 a heterogeneous IT environment. They utilize vendor-provided
659 automatable security configuration checklists for each operating
660 system and application used within their IT environment. Multiple
661 checklists are used from different vendors to ensure adequate
662 coverage of all IT assets." The usage scenario, as defined in the
663 RFC, is targeted at the checklist level and can be interpreted as
664 being specific to endpoint configuration. There is mention of
665 patch assessment and vulnerability mitigation, but the usage
666 scenario could be expanded upon by including vulnerability
667 verification. Replacing the idea of a checklist in the SACM usage
668 scenario with vulnerability would allow the usage scenario to
669 align almost exactly with the scenario described in this document.
670 Instead of collecting automatable security configuration
671 checklists, the enterprise would collect automatable vulnerability
672 description information available from the vendor as described or
673 possibly from other interested third-parties.
675 o Detection of Posture Deviations (2.2.3) - "An enterprise has
676 established secure configuration baselines for each different type
677 of endpoint within their IT environment. When an endpoint
678 connects to the network, the appropriate baseline configuration is
679 communicated to the endpoint. Once the baseline has been
680 established, the endpoint is monitored for any change events
681 pertaining to the baseline on an ongoing basis. When a change
682 occurs to posture defined in the baseline, updated posture
683 information is exchanged. When the endpoint detects a posture
684 change, an alert is generated identifying the specific changes in
685 posture." This usage scenario would support the concept of
686 endpoints signaling or alerting the enterprise to changes in the
687 posture relates to endpoint vulnerabilities in the same way that
688 it would for configurations. Replacing the idea of a checklist
689 with vulnerability description data allows the SACM usage scenario
690 and the scenario described in this document to align in their
691 objectives.
693 o Asynchronous Compliance/Vulnerability Assessment at Ice Station
694 Zebra (2.2.5) - "An isolated arctic IT environment that is
695 separated from the main university network. The only network
696 communications are via an intermittent, low-speed, high-latency,
697 high-cost satellite link. Remote network admins will need to show
698 continued compliance with the security policies of the university,
699 the government, and the provider of the satellite network, as well
700 as keep current on vulnerability testing." This SACM usage
701 scenario describes vulnerability assessment and aligns well with
702 the vulnerability scenario described in this document. The
703 endpoint assets are identified and associated data is published in
704 a Repository. Vulnerability description information is collected
705 and saved in a Repository as it is released. The vulnerability
706 description information is queued for later assessment, then the
707 assessment results and vulnerability description information are
708 stored after assessment. The only real difference in this SACM
709 usage scenario is the timing of the assessments. The scenario
710 described within this document would have no problems adjusting to
711 the timing of this SACM usage scenario or anything similar.
713 Appendix E. SACM Requirements and Charter - Future Work
715 In the course authoring this document, some additional considerations
716 for possible future work were noted. The following points were taken
717 from the SACM Requirements [I-D.ietf-sacm-requirements], SACM Charter
718 [charter-ietf-sacm-01], and SACM Use Cases ([RFC7632]) documents and
719 represent work that may be necessary to support the tasks or goals of
720 SACM going forward.
722 o The SACM requirements mentions "Result Reporting" with
723 applications but no detail around what the assessment results data
724 set should include. In the case of vulnerability assessment
725 results, context is important and details beyond just a Pass or
726 Fail result are needed in order to take action. A good example of
727 this might be the Priority of the vulnerability itself and how
728 many systems it affects within the enterprise. With this in mind,
729 it might be worthwhile to investigate a minimum data set or schema
730 for assessment results. The concern here is with vulnerability
731 description data, but this could apply to other enterprise
732 processes as well.
734 o The "Human-assigned endpoint attributes" mentioned previously in
735 this scenario are touched on in the SACM use cases, but the topic
736 could probably be explored in much more depth. Enterprise policy
737 and behaviors could be greatly influenced by endpoint attributes
738 such as locations, how the endpoint is used, and criticality.
739 When and how these data attributes are collected, as well as what
740 the minimum or common set might look like, would be good topics
741 for future related SACM work. In addition, the storage of these
742 attributes could be central (stored in a data repository) or they
743 could be assigned and stored on the endpoints themselves.
745 Appendix F. SACM Use Case Alignment
747 F.1. Endpoint Identification
749 This sub-step aligns with the Endpoint Discovery, Endpoint
750 Characterization, and Endpoint Target Identification building block
751 capabilities. The alignment is due to the fact that the purpose of
752 this sub-step is to discover, identify, and characterize all
753 endpoints on an enterprise network.
755 F.2. Endpoint Data Collection
757 This sub-step aligns with the Data Publication building block
758 capability because this section involves storage of endpoint
759 attributes within an enterprise Repository. This sub-step also
760 aligns with the Endpoint Characterization and Endpoint Target
761 Identification building block capabilities because it further
762 characterizes the endpoint through automated and possibly manual
763 means. There is direct alignment with the Endpoint Component
764 Inventory, Posture Attribute Identification, and Posture Attribute
765 Value Collection building block capabilities since the purpose of
766 this sub-step is to perform an initial inventory of the endpoint and
767 collect basic attributes and their values. Last, there is alignment
768 with the Collection Guidance Acquisition building block capabilities
769 as the inventory and collection of endpoint attributes would be
770 directed by some type of enterprise or third-party guidance.
772 F.3. Vulnerability Description Information
774 This step aligns with the Data Publication and Data Retrieval
775 building block capabilities because this section details storage of
776 vulnerability description information within an enterprise Repository
777 and later retrieval of the same.
779 F.4. Applicability
781 This sub-step aligns with the Data Retrieval, Data Query, and Posture
782 Attribute Value Query building block capabilities because, in this
783 sub-step, the process is attempting to determine the vulnerability
784 status of the endpoint using the data that has previously been
785 collected.
787 F.5. Secondary Assessment
789 This sub-step aligns with the Data Publication building block
790 capability because this section details storage of endpoint
791 attributes within an enterprise Repository. The sub-step also aligns
792 with the Collection Guidance Acquisition building block capability
793 since the vulnerability description information (guidance) drives the
794 collection of additional endpoint attributes.
796 This sub-step aligns with the Endpoint Characterization (both manual
797 and automated) and Endpoint Target Identification building block
798 capabilities because it could further characterize the endpoint
799 through automated and possibly manual means. There is direct
800 alignment with the Endpoint Component Inventory, Posture Attribute
801 Identification, and Posture Attribute Value Collection building block
802 capabilities since the purpose of this sub-step is to perform
803 additional and more specific component inventories and collections of
804 endpoint attributes and their values.
806 F.6. Assessment Results
808 This step aligns with the Data Publication and Data Retrieval
809 building block capabilities because this section details storage of
810 vulnerability assessment results within an enterprise Repository and
811 later retrieval of the same.
813 Appendix G. Alignment with Other Existing Works
815 G.1. Critical Security Controls
817 The Center for Internet Security's Critical Security Controls
818 [critical-controls] includes security controls for a number of usage
819 scenarios, some of which are covered in this document. This section
820 documents the alignment between the Center's controls and the
821 relevant elements of the scenario.
823 G.1.1. Continuous Vulnerability Assessment
825 "CSC 4: Continuous Vulnerability Assessment and Remediation," which
826 is described by the Center for Internet Security as "Continuously
827 acquire, assess, and take action on new information in order to
828 identify vulnerabilities, remediate, and minimize the window of
829 opportunity for attackers." The scenario described in this document
830 is aligned with CSC 4 in multiple ways:
832 CSC 4.1 applies to this scenario in that it calls for running
833 regular, automated scanning to deliver prioritized lists of
834 vulnerabilities with which to respond. The scenario described in
835 this document is intended to be executed on a continuous basis, and
836 the priorities of both vulnerability description information and the
837 remedy of vulnerabilities are discussed in the Priority section
838 earlier in this document.
840 This scenario assumes that the enterprise already has a source for
841 vulnerability description information as described in CSC 4.4.
843 Both CSC 4.2 and 4.7 are made possible by writing information to a
844 Repository since this makes previously collected data available for
845 later analysis.
847 While this scenario does not go into the details of how
848 prioritization would be calculated or applied, it does touch on some
849 of the important ways in which prioritization would impact the
850 endpoint assessment process in the Priority section. As such, the
851 Priority section aligns with CSC 4.8, which deals with vulnerability
852 priority. Vulnerability priority in this scenario is discussed in
853 terms of the vulnerability description information priority during
854 receipt, as well as the vulnerability priority with regards to
855 remedies.
857 The described scenario does not address the details of applying a
858 remedy based on assessment results. As such, CSC 4.5 which deals
859 with mitigations and patching, is out of scope for this work.
860 Similarly, CSC 4.3 prescribes performing scans in authenticated mode
861 and CSC 4.6 prescribes monitoring logs. This scenario does not get
862 into the means by which data is collected, focusing on "what" to
863 collect rather than "how", and as such does not have corresponding
864 sections, although the procedures described are not incompatible with
865 either of these controls.
867 The CSC 4 System Entity Relationship diagram directly aligns with the
868 scenario described in this document with the exception of applying
869 patches to endpoints.
871 G.1.2. Hardware and Software Inventories
873 This scenario is also aligned with, and describes a process for,
874 collecting and maintaining hardware and software inventories, which
875 are covered by the Center for Internet Security CSC 1 "Inventory of
876 Authorized and Unauthorized Devices" and CSC 2 "Inventory of
877 Authorized and Unauthorized Software." This scenario documents a
878 process that is specific to collecting and maintaining hardware and
879 software data attributes for vulnerability assessment purposes, but
880 the collection of the hardware attributes and software inventory
881 documented in the Endpoint Data Collection section that follows can
882 also be used for the purpose of implementing authorized and
883 unauthorized hardware and software management processes (e.g.,
884 scanning tools looking for unauthorized software). Moreover, the
885 ability to accurately identify endpoints and, to a lesser degree,
886 applications is integral to effective endpoint data collection and
887 vulnerability management.
889 The Endpoint Data Collection section does not have coverage for the
890 specific details described in CSC 1 and 2 as they are different
891 processes and would be out-of-scope of this scenario, but the section
892 does provide the data necessary to support the controls.
894 The Endpoint Identification and Endpoint Data Collection sections
895 within this scenario align with CSC 1.1 and 1.4 by identifying
896 enterprise endpoints and collecting their hardware and network
897 attributes. The Endpoint Data Collection section aligns with and
898 supports CSC 2.3 by defining a software inventory process and a
899 method of obtaining operating system and file system attributes. The
900 rest of the items from CSC 1 and 2 deal with implementation details
901 and would be out-of-scope for this document.
903 Appendix H. Continuous Vulnerability Assessment
905 It is not sufficient to perform a single assessment when
906 vulnerability description information is published without any
907 further checking. Doing so does not address the possibility that the
908 reported vulnerability might be introduced to the enterprise
909 environment after the initial assessment completes. For example, new
910 endpoints can be introduced to the environment which have old
911 software or are not up-to-date with patches. Another example is
912 where unauthorized or obsolete software is installed on an existing
913 endpoint by enterprise users after vulnerability description
914 information and initial assessment has taken place. Moreover,
915 enterprises might not wish to, or be able to, assess all
916 vulnerability description information immediately when they come in.
917 Conflicts with other critical activities or limited resources might
918 mean that some alerts, especially those that the enterprise deems as
919 "low priority", are not used to guide enterprise assessments until
920 sometime after the initial receipt.
922 The scenario above describes a single assessment of endpoints.
923 However, it does not make any assumptions as to when this assessment
924 occurs relative to the original receipt of the vulnerability
925 description data that led to this assessment. The assessment could
926 immediately follow the ingestion of the vulnerability description
927 information, could be delayed, or the assessment might represent a
928 reassessment of some vulnerability description information against
929 which endpoints had previously been assessed. Moreover, the scenario
930 incorporates long-term storage of collected data, vulnerability
931 description information, and assessment results in order to
932 facilitate meaningful and ongoing reassessment.
934 Appendix I. Data Attribute Table
936 The following table maps all major data attributes against each major
937 process where they are used.
939 +--------------+------------+-------------+-------------+-----------+
940 | | vulnerabil | Endpoint Id | Endpoint Ap | Assessmen |
941 | | ity descri | entificatio | plicability | t Results |
942 | | ption data | n and | and | |
943 | | | Initial | Assessment | |
944 | | | Data | | |
945 | | | Collection | | |
946 +--------------+------------+-------------+-------------+-----------+
947 | *Endpoint* | | | | |
948 +--------------+------------+-------------+-------------+-----------+
949 | Collection | | X | X | |
950 | date/time | | | | |
951 +--------------+------------+-------------+-------------+-----------+
952 | Endpoint | | X | X | |
953 | type | | | | |
954 +--------------+------------+-------------+-------------+-----------+
955 | Hardware ver | X | X | X | |
956 | sion/firmwar | | | | |
957 | e | | | | |
958 +--------------+------------+-------------+-------------+-----------+
959 | Operating | X | X | X | |
960 | system | | | | |
961 +--------------+------------+-------------+-------------+-----------+
962 | Operating | X | X | X | |
963 | system | | | | |
964 | attributes | | | | |
965 | (e.g., | | | | |
966 | version, | | | | |
967 | service pack | | | | |
968 | level, | | | | |
969 | edition, | | | | |
970 | etc.) | | | | |
971 +--------------+------------+-------------+-------------+-----------+
972 | Installed | X | X | X | X |
973 | software | | | | |
974 | name | | | | |
975 +--------------+------------+-------------+-------------+-----------+
976 | Installed | X | X | X | X |
977 | software | | | | |
978 | attributes | | | | |
979 | (e.g., | | | | |
980 | version, | | | | |
981 | patch level, | | | | |
982 | install | | | | |
983 | path, etc.) | | | | |
984 +--------------+------------+-------------+-------------+-----------+
985 | Open ports/s | X | X | X | |
986 | ervices | | | | |
987 +--------------+------------+-------------+-------------+-----------+
988 | Operating | X | X | X | |
989 | system | | | | |
990 | optional | | | | |
991 | component | | | | |
992 | inventory | | | | |
993 +--------------+------------+-------------+-------------+-----------+
994 | Location | | X | | X |
995 +--------------+------------+-------------+-------------+-----------+
996 | Purpose | | X | | X |
997 +--------------+------------+-------------+-------------+-----------+
998 | Criticality | | X | | X |
999 +--------------+------------+-------------+-------------+-----------+
1000 | File system | X | | X | |
1001 | attributes | | | | |
1002 | (e.g., | | | | |
1003 | versions, | | | | |
1004 | size, write | | | | |
1005 | date, | | | | |
1006 | modified | | | | |
1007 | date, | | | | |
1008 | checksum, | | | | |
1009 | etc.) | | | | |
1010 +--------------+------------+-------------+-------------+-----------+
1011 | Shared | X | | X | |
1012 | libraries | | | | |
1013 +--------------+------------+-------------+-------------+-----------+
1014 | Other | X | | X | |
1015 | software con | | | | |
1016 | figuration | | | | |
1017 | information | | | | |
1018 +--------------+------------+-------------+-------------+-----------+
1019 | *External vu | | | | |
1020 | lnerability | | | | |
1021 | description | | | | |
1022 | data* | | | | |
1023 +--------------+------------+-------------+-------------+-----------+
1024 | Ingest Date | X | | X | |
1025 +--------------+------------+-------------+-------------+-----------+
1026 | Date of | X | | X | |
1027 | Release | | | | |
1028 +--------------+------------+-------------+-------------+-----------+
1029 | Version | X | | X | |
1030 +--------------+------------+-------------+-------------+-----------+
1031 | External | X | | X | X |
1032 | vuln ID | | | | |
1033 +--------------+------------+-------------+-------------+-----------+
1034 | Severity | | | | X |
1035 | Score | | | | |
1036 +--------------+------------+-------------+-------------+-----------+
1037 | *Assessment | | | | |
1038 | Results* | | | | |
1039 +--------------+------------+-------------+-------------+-----------+
1040 | Date of | | | X | X |
1041 | assessment | | | | |
1042 +--------------+------------+-------------+-------------+-----------+
1043 | Date of data | | X | X | X |
1044 | collection | | | | |
1045 +--------------+------------+-------------+-------------+-----------+
1046 | Endpoint ide | | X | X | X |
1047 | ntification | | | | |
1048 | and/or | | | | |
1049 | locally | | | | |
1050 | assigned ID | | | | |
1051 +--------------+------------+-------------+-------------+-----------+
1052 | Vulnerable | X | X | X | X |
1053 | software | | | | |
1054 | product(s) | | | | |
1055 +--------------+------------+-------------+-------------+-----------+
1056 | Endpoint vul | | | X | X |
1057 | nerability | | | | |
1058 | status | | | | |
1059 +--------------+------------+-------------+-------------+-----------+
1060 | Vulnerabilit | X | | | X |
1061 | y | | | | |
1062 | description | | | | |
1063 +--------------+------------+-------------+-------------+-----------+
1064 | Vulnerabilit | X | | | X |
1065 | y | | | | |
1066 | remediation | | | | |
1067 +--------------+------------+-------------+-------------+-----------+
1069 Table 1: Vulnerability Assessment Attributes
1071 Authors' Addresses
1073 Christopher Coffin
1074 The MITRE Corporation
1075 202 Burlington Road
1076 Bedford, MA 01730
1077 USA
1079 Email: ccoffin@mitre.org
1081 Brant Cheikes
1082 The MITRE Corporation
1083 202 Burlington Road
1084 Bedford, MA 01730
1085 USA
1087 Email: bcheikes@mitre.org
1088 Charles Schmidt
1089 The MITRE Corporation
1090 202 Burlington Road
1091 Bedford, MA 01730
1092 USA
1094 Email: cmschmidt@mitre.org
1096 Daniel Haynes
1097 The MITRE Corporation
1098 202 Burlington Road
1099 Bedford, MA 01730
1100 USA
1102 Email: dhaynes@mitre.org
1104 Jessica Fitzgerald-McKay
1105 Department of Defense
1106 9800 Savage Road
1107 Ft. Meade, Maryland
1108 USA
1110 Email: jmfitz2@nsa.gov
1112 David Waltermire
1113 National Institute of Standards and Technology
1114 100 Bureau Drive
1115 Gaithersburg, Maryland 20877
1116 USA
1118 Email: david.waltermire@nist.gov