idnits 2.17.00 (12 Aug 2021) /tmp/idnits42422/draft-waltermire-scap-xccdf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 75 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A Value object MAY extend another Value object. In such cases, the extending object SHALL receive all the properties of the extended object, and MAY override them where needed. A Value object with the abstract property true SHALL NOT be included in any generated document, and MAY NOT be exported to any compliance checking engine. -- The document date (October 18, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SCAP Working Group D. Waltermire 2 Internet Draft NIST 3 Intended status: Informational October 18, 2010 4 Expires: April 18, 2011 6 The Extensible Configuration Checklist Description Format (XCCDF) 7 Version 1.1.4 8 draft-waltermire-scap-xccdf-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to publish it 15 as an RFC and to translate it into languages other than English. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 18, 2009. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This document specifies the data model and Extensible Markup 53 Language (XML) representation for the Extensible Configuration 54 Checklist Description Format (XCCDF) Version 1.1.4. An XCCDF 55 document is a structured collection of security configuration rules 56 for some set of target systems. The XCCDF specification is designed 57 to support information interchange, document generation, 58 organizational and situational tailoring, automated compliance 59 testing, and compliance scoring. The specification also defines a 60 data model and format for storing results of security guidance or 61 checklist compliance testing. The intent of XCCDF is to provide a 62 uniform foundation for expression of security checklists and other 63 configuration guidance, and thereby foster more widespread 64 application of good security practices. 66 Table of Contents 68 1. Introduction...................................................5 69 2. Conventions used in this document..............................6 70 3. Background.....................................................6 71 3.1. Motivation................................................7 72 3.2. Vision for Use............................................8 73 3.3. Summary of Changes since Version 1.0......................9 74 4. High-Level Requirements for XCCDF..............................9 75 4.1. Structure and Tailoring Requirements.....................11 76 4.2. Inheritance and Inclusion Requirements...................13 77 4.3. Document and Report Formatting Requirements..............14 78 4.4. Rule Checking Requirements...............................14 79 4.5. Test Results Requirements................................15 80 4.6. Metadata and Security Requirements.......................16 81 5. Data Model....................................................17 82 5.1. Benchmark Structure......................................19 83 5.1.1. Inheritance.........................................20 84 5.2. Object Content Details...................................21 85 5.2.1. Benchmark...........................................21 86 5.2.2. Item................................................24 87 5.2.2.1. Group::Item....................................26 88 5.2.2.2. Rule::Item.....................................28 89 5.2.2.3. Value::Item....................................33 90 5.2.3. Profile.............................................36 91 5.2.4. TestResult..........................................38 92 5.2.4.1. TestResult/rule-result.........................41 93 5.3. Processing Models........................................44 94 5.3.1. Loading Processing Sequence.........................45 95 5.3.2. Traversal Processing Sequence.......................48 96 5.3.2.1. Benchmark Processing Algorithm.................48 97 5.3.2.2. Item Processing Algorithm......................49 98 5.3.3. Substitution Processing.............................51 99 5.3.4. Rule Application and Compliance Scoring.............51 100 5.3.5. Scoring and Results Model...........................52 101 5.3.6. Score Computation Algorithms........................54 102 5.3.6.1. The Default Model..............................54 103 5.3.6.2. The Flat Model.................................55 104 5.3.6.3. The Flat Unweighted Model......................56 105 5.3.6.4. The Absolute Model.............................56 106 5.3.7. Multiply-Instantiated Rules.........................56 107 6. XML Representation............................................57 108 6.1. XML Document General Considerations......................57 109 6.2. XML Element Dictionary...................................58 110 6.2.1. .........................................59 111 6.2.2. .............................................59 112 6.2.3. ..............................................61 113 6.2.4. .............................................62 114 6.2.5. ...........................................63 115 6.2.6. ........................................64 116 6.2.7. Other Elements and Attributes.......................65 117 6.2.7.1. ....................................66 118 6.2.7.2. ........................................66 119 6.2.7.3. .................................67 120 6.2.7.4. .................................68 121 6.2.7.5. ................................68 122 6.2.7.6. ............................68 123 6.2.7.7. ......................................69 124 6.2.7.8. .......................................69 125 6.2.7.9. ................................70 126 6.2.7.10. ...................................71 127 6.2.7.11. ....................................72 128 6.2.7.12. .....................................72 129 6.2.7.13. .................................72 130 6.2.7.14. ........................................73 131 6.2.7.15. .........................................73 132 6.2.7.16. .....................................76 133 6.2.7.17. ................................77 134 6.2.7.18. .......................................77 135 6.2.7.19. ....................................77 136 6.2.7.20. ...............................78 137 6.2.7.21. ....................................79 138 6.2.7.22. .................................80 139 6.2.7.23. .......................................80 140 6.2.7.24. .....................................81 141 6.2.7.25. ....................................81 142 6.2.7.26. .......................................82 143 6.2.7.27. ..................................83 144 6.2.7.28. ......................................83 145 6.2.7.29. ..................................83 146 6.2.7.30. ................................84 147 6.2.7.31. ....................................84 148 6.2.7.32. .......................................85 149 6.2.7.33. ..................................86 150 6.2.7.34. ....................................86 151 6.2.7.35. ......................87 152 6.2.7.36. , 153 ........................................................87 154 6.2.7.37. .....................................88 155 6.2.7.38. ................................88 156 6.2.7.39. ....................................88 157 6.2.7.40. ...................................89 158 6.2.7.41. .................................89 159 6.2.7.42. ...................................89 160 6.2.7.43. .................................90 161 6.2.7.44. ................................91 162 6.2.7.45. ......................................92 163 6.2.7.46. ....................................92 164 6.2.7.47. ......................................93 165 6.2.7.48. .................................93 166 6.2.7.49. .......................................94 167 6.2.7.50. 4284 This element is part of a Profile; it overrides the selected 4285 attribute of a Rule or Group. Two attributes MUST be given with this 4286 element: the id of a Rule or Group (idref), and a boolean value 4287 (selected). If the boolean value is given as true, then the Rule or 4288 Group SHALL be selected for this Profile, otherwise it SHALL be 4289 unselected for this Profile. 4291 o Content: none 4293 o Cardinality: 0-n 4295 o Parent Elements: Profile 4297 o Attributes: idref+, selected+ 4299 o Child Elements: none 4301 The 'idref' attribute MUST match the id attribute of a Group or Rule 4302 in the Benchmark, or the cluster id assigned to one or more Rules or 4303 Groups. The 'idref' attribute values of sibling select element 4304 children of a Profile MUST be different. 4306 6.2.7.51. 4308 This element specifies a value for a Value object. It MAY appear as 4309 part of a Profile; in that case it overrides the value property of a 4310 Value object. It MAY appear as part of a TestResult; in that case it 4311 supplies the value used in the test. 4313 o Content: string 4315 o Cardinality: 0-n 4317 o Parent Elements: Profile, TestResult 4319 o Attributes: idref+ 4321 o Child Elements: none 4323 In the content of a Profile, the identifier given for the 'idref' 4324 attribute MAY be a cluster id, in which case it applies only to the 4325 Value item members of the cluster; in the context of a TestResult, 4326 the identifier MUST match the id of a Value object in the Benchmark. 4327 The 'idref' attribute values of sibling set-value element children 4328 of a Profile MUST be different. 4330 6.2.7.52. 4332 This element MAY hold an enveloped digital signature expressed 4333 according to the XML Digital Signature standard [6]. This element 4334 MUST contain exactly one element, Signature from the XML-Signature 4335 namespace. 4337 o Content: elements 4339 o Cardinality: 0-1 4341 o Parent Elements: Benchmark, Rule, Group, Value, Profile, 4342 TestResult 4344 o Attributes: none 4346 o Child Elements: Signature* (in XML-Signature namespace) 4348 At most one enveloped signature MAY appear in an XCCDF document. If 4349 multiple signatures are needed, others MUST be detached signatures. 4351 The Signature element SHOULD contain exactly one Reference to the 4352 block enclosing the signature. The Reference URI SHOULD be a 4353 relative URI to the Id attribute value of the enclosing object. For 4354 example, if the Id="abc", then the Reference URI would be "#abc". 4356 6.2.7.53. 4358 The source element contains a URI indicating where a tailoring or 4359 benchmarking tool might obtain the value, or information about the 4360 value, for a Value object. XCCDF does not attach any meaning to the 4361 URI; it MAY be an arbitrary community or tool-specific value, or a 4362 pointer directly to a resource. 4364 o Content: none 4366 o Cardinality: 0-n 4368 o Parent Elements: Value 4370 o Attributes: uri 4372 o Child Elements: none 4374 If several values for the source property appear, then they 4375 represent alternative means or locations for obtaining the value, in 4376 descending order of preference (i.e., most preferred first). 4378 6.2.7.54. 4380 This element provides a revision or standardization status for a 4381 Benchmark, along with the date at which the Benchmark attained that 4382 status. It MUST appear at least once in a Benchmark object, and MAY 4383 appear once or more than once in any Item. If an Item does not have 4384 its own status element, its status SHALL be that of its parent 4385 element. The permitted string values for status are "accepted", 4386 "deprecated", "draft", "interim", and "incomplete". 4388 o Content: string (enumerated choices) 4390 o Cardinality: 0-n 4392 o Parent Elements: Benchmark, Rule, Group, Value, Profile 4394 o Attributes: date 4396 o Child Elements: none 4398 6.2.7.55. 4400 This element represents a reference to a parameter value that MAY be 4401 set during tailoring. The element SHALL NOT have any content, and 4402 MUST have its single attribute, idref. The idref attribute MUST 4403 equal the id attribute of either a Value object or a plain-text 4404 definition. 4406 o Content: none 4408 o Cardinality: 0-n 4410 o Parent Elements: description, fix, fixtext, front-matter, 4411 rationale, rear-matter, title, warning 4413 o Attributes: idref+ 4415 o Child Elements: none 4417 6.2.7.56. 4419 This element gives the name or description of a target system to 4420 which a Benchmark test was applied. It SHALL only appear as a child 4421 of a TestResult element. 4423 o Content: string 4425 o Cardinality: 1 4427 o Parent Elements: TestResult 4429 o Attributes: none 4431 o Child Elements: none 4433 6.2.7.57. 4435 This element gives the network address of a target system to which a 4436 Benchmark test was applied. It SHALL only appear as a child of a 4437 TestResult element. 4439 o Content: string 4441 o Cardinality: 0-n 4443 o Parent Elements: TestResult 4444 o Attributes: none 4446 o Child Elements: none 4448 6.2.7.58. 4450 The TestResult object can hold an arbitrary set of facts about the 4451 target of a test. This element holds those facts, each one of which 4452 is a fact element. It is an OPTIONAL member of TestResult. 4454 o Content: string 4456 o Cardinality: 0-1 4458 o Parent Elements: TestResult 4460 o Attributes: none 4462 o Child Elements: fact 4464 6.2.7.59. 4466 This element provides the descriptive title for a Benchmark, Rule, 4467 Group, or Value. Multiple instances MAY appear with different 4468 languages (different values of the xml:lang attribute). 4470 o Content: string 4472 o Cardinality: 0-n 4474 o Parent Elements: Benchmark, Value, Group, Rule, Profile, 4475 TestResult 4477 o Attributes: xml:lang, override 4479 o Child Elements: none 4481 This element SHALL NOT contain XHTML markup. 4483 The 'override' attribute controls how the title property is 4484 inherited, if the Item in which it appears extends another Item. 4486 6.2.7.60. <upper-bound> 4488 This element MAY appear one or more times as a child of a Value 4489 element. It is used to constrain value input during tailoring, when 4490 the Value's type is "number". It contains a number; values supplied 4491 by the user for tailoring the Benchmark MUST be no greater than this 4492 number. This element MAY have a selector tag attribute, which 4493 identifies it for Value refinement by a Profile. If more than one 4494 upper-bound element appears as the child of a Value, at most one MAY 4495 omit the selector attribute. 4497 o Content: number 4499 o Cardinality: 0-n 4501 o Parent Elements: Value 4503 o Attributes: selector 4505 o Child Elements: none 4507 6.2.7.61. <value> 4509 This string element is used to hold the value of a Value object. It 4510 MUST appear as the child of a Value element. This element MAY have a 4511 selector tag attribute, which identifies it for Value refinement by 4512 a Profile. This element MAY appear more than once, but at most one 4513 of the sibling instances of this element MAY omit the selector tag. 4515 o Content: String 4517 o Cardinality: 1-n 4519 o Parent Elements: Value 4521 o Attributes: Selector 4523 o Child Elements: None 4525 6.2.7.62. <version> 4527 This element gives a version number for a Benchmark, Group, Rule, 4528 Value, or Profile. The version number content MAY be any string. 4529 This element MAY have a time attribute, which is a timestamp of when 4530 the Object was defined. This element MAY also have an update 4531 attribute, which SHOULD be the URI specifying where updates to the 4532 Object may be obtained. 4534 o Content: string 4536 o Cardinality: 1 (Benchmark), 0-1 (all others) 4537 o Parent Elements: Benchmark, Group, Rule, Value, Profile 4539 o Attributes: time, update 4541 o Child Elements: none 4543 6.2.7.63. <warning> 4545 This element provides supplementary descriptive text for a 4546 Benchmark, Rule, Group, or Value. Multiple warning elements MAY 4547 appear; processing tools SHOULD concatenate them for generating 4548 reports or documents (see also Section 6.3). 4550 o Content: mixed 4552 o Cardinality: 0-n 4554 o Parent Elements: Benchmark, Group, Rule, Value 4556 o Attributes: xml:lang, override 4558 o Child Elements: sub, xhtml elements* 4560 This element is intended to convey important cautionary information 4561 for the Benchmark user (e.g., "Complying with this rule will cause 4562 the system to reject all IP packets"). Processing tools MAY present 4563 this information specially in generated documents. 4565 6.3. Handling Text and String Content 4567 This sub-section provides additional information about how XCCDF 4568 processing tools MUST handle textual content in Benchmarks. 4570 6.3.1. XHTML Formatting and Locale 4572 Some text-valued XCCDF elements MAY contain formatting specified 4573 with elements from the XHTML Core Recommendation. 4575 Many of the string and textual elements of XCCDF are listed as 4576 appearing multiple times under the same parent element. These 4577 elements, listed below, MAY have an xml:lang attribute that 4578 specifies the natural language locale for which they are written 4579 (e.g., "en" for English, "fr" for French). A processing tool SHOULD 4580 employ these attributes when possible during tailoring, document 4581 generation, and producing compliance reports, to create localized 4582 output. An example of using the xml:lang attribute is shown below. 4584 <cdf:Value id="web-server-port" type="number"> 4585 <cdf:title>Web Server Port</cdf:title> 4586 <cdf:question xml:lang="en"> 4587 What is the web server's TCP port? 4588 </cdf:question> 4589 <cdf:question xml:lang="fr"> 4590 Quel est le port du TCP du web serveur? 4591 </cdf:question> 4592 <cdf:value>80</cdf:value> 4593 </cdf:Value> 4595 Multiple values for the same property in a single Item are handled 4596 differently, as described below. Multiple instances with different 4597 values of their xml:lang attribute SHALL be permitted; an Item with 4598 no value for the xml:lang attribute SHALL be taken to have the same 4599 language as the Benchmark itself (as given by the xml:lang attribute 4600 on the Benchmark element). 4602 ----------------------------------------------------------------- 4603 Elements Inheritance Behavior 4604 ----------------------------------------------------------------- 4605 description, title, fixtext, At most one instance per language; 4606 rationale, question, inherited values with the same 4607 front-matter, rear-matter language get replaced 4608 ----------------------------------------------------------------- 4609 warning, reference, notice Multiple instances treated as an 4610 ordered list; inherited instances 4611 prepended to the list 4612 ----------------------------------------------------------------- 4614 The platform element MAY also appear multiple times, each with a 4615 different id, to express the notion that a Rule, Group, Benchmark, 4616 or Profile applies to several different products or systems. 4618 6.3.2. String Substitution and Reference Processing 4620 There are three kinds of string substitution and one kind of 4621 reference processing that XCCDF document generation and reporting 4622 tools MUST support. 4624 1. XCCDF sub element - The sub element supports substitution of 4625 information from a Value object, or the string content of a 4626 plain-text definition. The formatting for a sub element reference 4627 to a Value object is implementation-dependent for document 4628 generation, as described in Section 5.3. Formatting for a sub 4629 element reference to a plain-text definition is very simple: the 4630 string content of the plain-text definition replaces the sub 4631 element. 4633 2. XHTML object element - The object element supports substitutions 4634 of a variety of information from another Item or Profile, or the 4635 string content of a plain-text definition. To avoid possible 4636 conflicts with uses of an XHTML object that should not be 4637 processed specially, all XCCDF object references MUST be a 4638 relative URI beginning with "#xccdf:". The following URI values 4639 can be used to refer to things from an "object" element, using 4640 the "data" attribute: 4642 o #xccdf:value:id - Insert the value of the plain-text block, Value, 4643 or fact with id id:. When a URI of this form is used, the value 4644 of the reference SHOULD be substituted for the entire "object" 4645 element and its content (if any). In keeping with the standard 4646 semantics of XHTML, if the id cannot be resolved, then the 4647 textual content of the "object" element SHOULD be retained. 4649 o #xccdf:title:id - Insert the string content of the "title" child 4650 of the Item with id id. Use the current language value locale 4651 setting, if any. When a URI of this form is used, the title 4652 string SHOULD be substituted for the entire "object" element and 4653 its content (if any). In keeping with the standard semantics of 4654 XHTML, if the id cannot be resolved, then the textual content of 4655 the "object" element SHOULD be retained. 4657 3. XHTML anchor (a) element - The anchor element MAY be used to 4658 create an intra-document link to another XCCDF Item or Profile. 4659 To avoid possible conflicts with uses of the XHTML anchor element 4660 that should not be processed specially, all XCCDF anchor 4661 references MUST be a relative URI beginning with "#xccdf:". The 4662 following URI values can be used to refer to things from an 4663 anchor ("a") element, using the 'href' attribute: 4665 o #xccdf:link:id - Create an intra-document link to the point in the 4666 document where the Item id is described. The content of the 4667 element SHOULD be the text of the link. 4669 7. Security Considerations 4671 In most situations XCCDF is not security sensitive. An XCCDF 4672 checklist may expose information about the configuration of a system 4673 that attackers can use. In these cases confidentiality would be 4674 desireable; however, there is no mechanism to encrypt information. 4675 If confidentiality is needed, use TLS or other forms of external 4676 encryption. 4678 XML signature MAY be used within the XCCDF data model to add 4679 integrity and origin authentication. If you are using this for 4680 origin authentication, minimum key sizes SHOULD be RSA 1024 bit and 4681 SHA1. Implemetations SHOULD provide support for RSA 2048 bit or 4682 SHA256. 4684 8. IANA Considerations 4686 This document requires no action by IANA. 4688 9. This draft defines common URLs and URNs for use within this data 4689 model as defined in Appendix A. Uniqueness and semantics for these 4690 URLs and URNs has been handled as part of XCCDF maintenance. Future 4691 standards based upon XCCDF would be required to establish IANA 4692 registries for these values. The URLs and URNs in Appendix A would 4693 be the initial values for those registries.Conclusions 4695 The XCCDF specification defines a means for expressing security 4696 guidance documents in a way that should foster development of 4697 interoperable tools and content. It is designed to permit the same 4698 document to serve in several roles: 4700 o Source code for generation of publication documents and hardcopy 4702 o Script for eliciting local security policy settings and values 4703 from a user 4705 o Structure for containing and organizing code that drives system 4706 analysis and configuration checking engines 4708 o Source code for text to appear in security policy compliance 4709 reports 4711 o A record of a compliance test, including the results of applying 4712 various rules 4714 o Structure for expressing compliance scoring/weighting decisions. 4716 XCCDF 1.1 was designed as a compatible extension of 1.0, based on 4717 suggestions from early adopters and potential users. Many features 4718 have been added, but every valid 1.0 document SHOULD be a valid 1.1 4719 document, once the namespace is adjusted. The forward compatibility 4720 will help ensure that content written for XCCDF 1.0 will not be made 4721 obsolete by the 1.1 specification. XCCDF 1.1.4 is a minor update of 4722 the specification and schema of XCCDF 1.1, mainly to add clarity and 4723 fix problems identified by initial users. 4725 Adoption of a common format should permit security professionals, 4726 security tool vendors, and system auditors to exchange information 4727 more quickly and precisely, and also permit greater automation of 4728 security testing and configuration checking. 4730 10. References 4732 10.1. Normative References 4734 [1] Bradner, S., "Key words for use in RFCs to Indicate 4735 Requirement Levels", BCP 14, RFC 2119, March 1997. 4737 [2] Marsh, J. and Orchard, D., "XML Inclusions (XInclude) Version 4738 1.0", W3C Candidate Recommendation, April 2004. 4740 [3] Baker, M. et al, "XHTML Basic", W3C Recommendation, December 4741 2000. 4743 [4] Biron, P. and Malhotra, A., "XML Schema Part 2: Datatypes", 4744 W3C Recommendation, May 2001. 4746 [5] Buttner, A., and Ziring, N., "Common Platform Enumeration 4747 (CPE) - Specification, Version 2.2", MITRE Corporation, March 4748 2009. 4750 [6] Bartel, M. et al, "XML - Signature Syntax and Processing", W3C 4751 Recommendation, February 2002. 4753 [7] Mell, P., Romanosky, S., and Scarfone, K., "A Complete Guide 4754 to the Common Vulnerability Scoring System Version 2.0", 4755 FIRST, June 2007. 4757 [8] Davis, M., "Unicode Regular Expressions", Unicode Technical 4758 Recommendation No. 18, version 9, January 2004. 4760 [9] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 4761 Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 4762 2005. 4764 10.2. Informative References 4766 [10] Quinn, S. et al, "National Checklist Program for IT Products - - 4767 Guidelines for Checklist Users and Developers", NIST Special 4768 Publication 800-70 Revision 1, September 2009. 4770 [11] "OVAL - The Open Vulnerability and Assessment Language", The 4771 MITRE Corporation, September 2006. 4773 [12] Johnston, P. and Powell, A., "Guidelines for Implementing 4774 Dublin Core in XML", DCMI, April 2003. 4776 [13] Hillmann, D., "Using Dublin Core", DCMI, August 2003. 4778 11. Acknowledgments 4780 This draft is based on the NIST Interagency Report (IR) 7275 4781 revision 3 authored by Neal Ziring of the NSA and Stephen D. Quinn 4782 of NIST. This document is the result of the collective effort of a 4783 large number of people including the following individuals who 4784 contributed to the initial definition and development of XCCDF: 4785 David Proulx, Mike Michnikov, Andrew Buttner, Todd Wittbold, Adam 4786 Compton, George Jones, Chris Calabrese, John Banghart, Murugiah 4787 Souppaya, John Wack, Trent Pitsenbarger, and Robert Stafford. 4789 Peter Mell and Matthew Wojcik contributed to Revisions 1, 2, and 3 4790 of the NISTIR 7275. Karen Scarfone provided editorial comments and 4791 changes to all historic revisions and to this draft. Ryan Wilson of 4792 Georgia Institute of Technology also made substantial contributions. 4793 Thanks also go to the DISA Field Security Office (FSO) Vulnerability 4794 Management System (VMS)/Gold Disk team for extensive review and many 4795 suggestions. 4797 This document was prepared using 2-Word-v2.0.template.dot. 4799 Appendix A. Pre-Defined URIs 4801 The following URLs and URNs are defined for XCCDF 1.1. 4803 A.1. Long-Term Identification Systems 4805 These URIs may appear as the value of the system attribute of an 4806 ident element (see page 59). 4808 http://cve.mitre.org/ - MITRE's Common Vulnerabilities and Exposures 4809 - the identifier value should be a CVE number or CVE candidate 4810 number. 4812 http://cce.mitre.org/ - This specifies the Common Configuration 4813 Enumeration identifier scheme. 4815 http://www.cert.org/ - CERT Coordination Center - the identifier 4816 value should be a CERT advisory identifier (e.g. "CA-2004-02"). 4818 http://www.us-cert.gov/cas/techalerts/ - US-CERT technical cyber 4819 security alerts - the identifier value should be a technical cyber 4820 security alert ID (e.g., "TA05-189A") 4822 http://www.kb.cert.org/ - US-CERT vulnerability notes database - the 4823 identifier values should be a vulnerability note number (e.g., 4824 "709220"). 4826 http://iase.disa.mil/IAalerts/ - DISA Information Assurance 4827 Vulnerability Alerts (IAVA) - the identifier value should be a DOD 4828 IAVA identifier. 4830 A.2. Check Systems 4832 These URIs may appear as the value of the system attribute of a 4833 check element (see p. 50). 4835 http://oval.mitre.org/XMLSchema/oval - MITRE's Open Vulnerability 4836 Assessment Language (see [11]). 4838 http://www.cisecurity.org/xccdf/interactive/1.0 - Center for 4839 Internet Security interactive query check system, used for asking 4840 the user questions about the target system during application of a 4841 security guidance document. 4843 Other check systems are being developed and used to support many use 4844 cases. This listing includes publicly released check systems 4845 available at the release of this draft. 4847 A.3. Scoring Models 4849 These URIs may appear as the value of the system attribute on the 4850 model element or a score element (see pp. 62 and 71). 4852 urn:xccdf:scoring:default - This specifies the default (XCCDF 1.0) 4853 scoring model. 4855 urn:xccdf:scoring:flat - This specifies the flat, weighted scoring 4856 model. 4858 urn:xccdf:scoring:flat-unweighted - This specifies the flat scoring 4859 model with weights ignored (all weights set to 1). 4861 urn:xccdf:scoring:absolute - This specifies the absolute (1 or 0) 4862 scoring model. 4864 A.4. Target Platform Facts 4866 The following URNs should be used to record facts about an IT asset 4867 (target) to which a Benchmark TestResult applies (see pages 49 and 4868 75). 4870 urn:scap:fact:asset:identifier:mac - Ethernet media access control 4871 address (should be sent as a pair with the IP or IPv6 address to 4872 ensure uniqueness) 4874 urn:scap:fact:asset:identifier:ipv4 - Internet Protocol version 4 4875 address 4877 urn:scap:fact:asset:identifier:ipv6 - Internet Protocol version 6 4878 address 4880 urn:scap:fact:asset:identifier:host_name - Host name of the asset, 4881 if assigned 4883 urn:scap:fact:asset:identifier:fqdn - Fully qualified domain name 4885 urn:scap:fact:asset:identifier:ein - Equipment identification number 4886 or other inventory tag number 4888 urn:scap:fact:asset:identifier:pki: - X.509 PKI certificate for the 4889 asset (encoded in Base-64) 4891 urn:scap:fact:asset:identifier:pki:thumbprint - SHA.1 hash of the 4892 PKI certification for the asset (encoded in Base-64) 4893 urn:scap:fact:asset:identifier:guid - Globally unique identifier for 4894 the asset 4896 urn:scap:fact:asset:identifier:ldap - LDAP directory string 4897 (distinguished name) of the asset, if assigned 4899 urn:scap:fact:asset:identifier:active_directory - Active Directory 4900 realm to which the asset belongs, if assigned 4902 urn:scap:fact:asset:identifier:nis_domain - NIS domain of the asset, 4903 if assigned 4905 urn:scap:fact:asset:environmental_information:owning_organization - 4906 Organization that tracks the asset on its inventory 4908 urn:scap:fact:asset:environmental_information:current_region - 4909 Geographic region where the asset is located 4911 urn:scap:fact:asset:environmental_information:administration_unit - 4912 Name of the organization that does system administration for the 4913 asset 4915 urn:scap:fact:asset:environmental_information:administration_poc:tit 4916 le - Title (e.g., Mr, Ms, Col) of the system administrator for an 4917 asset] 4919 urn:scap:fact:asset:environmental_information:administration_poc:e- 4920 mail - E-mail address of the system administrator for the asset 4922 urn:scap:fact:asset:environmental_information:administration_poc:fir 4923 st_name - First name of the system administrator for the asset 4925 urn:scap:fact:asset:environmental_information:administration_poc:las 4926 t_name - Last name of the system administrator for the asset 4928 A.5. Remediation Systems 4930 The URIs represent remediation sources, mechanisms, schemes, or 4931 providers. They may appear as the system attribute on a fix element 4932 (see p. 56). 4934 urn:xccdf:fix:commands - This specifies that the content of the fix 4935 element is a list of target system commands; executed in order, the 4936 commands should bring the target system into compliance with the 4937 Rule. 4939 urn:xccdf:fix:urls - This specifies that the content of the fix 4940 element is a list of one or more URLs. The resources identified by 4941 the URLs should be applied to bring the system into compliance with 4942 the Rule. 4944 urn:xccdf:fix:script:{LANGUAGE} - A URN of this form specifies that 4945 the content of the fix element is a script written in the given 4946 language as specified by the {LANGUAGE} term. Executing the script 4947 should bring the target system into compliance with the Rule. The 4948 following {LANGUAGE} terms are pre-defined: 4950 o sh - Bourne shell 4952 o csh - C Shell 4954 o perl - Perl 4956 o batch - Windows batch script 4958 o python - Python and all Python-based scripting languages 4960 o vbscript - Visual Basic Script (VBS) 4962 o javascript - Javascript (ECMAScript, JScript) 4964 o tcl - Tcl and all Tcl-based scripting languages 4966 urn:xccdf:fix:patch:vendor - A URN of this form specifies that the 4967 content of the fix element is a patch identifier, in proprietary 4968 format as defined by the vendor. The vendor string should be the DNS 4969 domain name of the vendor, as defined in the CPE 2.2 specification 4970 [5]. For example, for Microsoft Corporation, the DNS domain is 4971 "microsoft.com", and the CPE vendor name would be "microsoft". 4973 Copyright (c) 2010 IETF Trust and the persons identified as authors 4974 of the code. All rights reserved. 4976 Redistribution and use in source and binary forms, with or without 4977 modification, are permitted provided that the following conditions 4978 are met: 4980 o Redistributions of source code must retain the above copyright 4981 notice, this list of conditions and the following disclaimer. 4983 o Redistributions in binary form must reproduce the above copyright 4984 notice, this list of conditions and the following disclaimer in 4985 the documentation and/or other materials provided with the 4986 distribution. 4988 o Neither the name of Internet Society, IETF or IETF Trust, nor the 4989 names of specific contributors, may be used to endorse or promote 4990 products derived from this software without specific prior 4991 written permission. 4993 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 4994 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 4995 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 4996 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 4997 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 4998 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 4999 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 5000 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 5001 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 5002 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 5003 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 5004 POSSIBILITY OF SUCH DAMAGE. 5006 Authors' Address 5008 David Waltermire 5009 NIST 5010 100 Bureau Drive, Stop 8930 5011 Gaithersburg, MD 20899-8930 5013 Email: david.waltermire@nist.gov