idnits 2.17.1 draft-inacio-sacm-infomodel-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 25, 2019) is 1738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 6919 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sacm C. Inacio 3 Internet-Draft CMU 4 Intended status: Standards Track July 25, 2019 5 Expires: January 26, 2020 7 SACM Information Model 8 draft-inacio-sacm-infomodel-00 10 Abstract 12 This defines the information model for the Security Automation and 13 Continuous Monitoring (SACM) standards. The working group faces a 14 set of complex issues when trying to define an information model that 15 complicates this effort: 17 o There are many standards in the SACM space which are not 18 interoperable 20 o There exists an extremely large and diverse set of data types 21 which are desirable to exchange 23 o Many data types depend on the operating systems from which they 24 are collected; making a universal typing harder 26 o A goal of SACM is to cover a diverse set of system types 28 These complex needs create a information model which is difficult to 29 unify within the environment. Instead, this information model design 30 is focused on minimum needed functionality with the desire to include 31 a type system design into the information model allowing for easy 32 expandability. It is envisioned that this information model will 33 serve the following purposes: 35 o Enough well specified elements in order to exchange key data 36 fields between systems 38 o Sufficient typing system to expand key fields over time and use of 39 a registry to standardize common expansions 41 o Meta information such that compplete information exchange using 42 various other formats understood by all parties can be used as 43 needed to exchange complete records on demand 45 o Sufficient action verbs defined to allow orchestration between 46 various systems to allow unified control of federated components 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on January 26, 2020. 65 Copyright Notice 67 Copyright (c) 2019 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (https://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 84 2. Minimal Needed Information Elements . . . . . . . . . . . . . 4 85 3. Information Element Metadata . . . . . . . . . . . . . . . . 4 86 3.1. Information Elements . . . . . . . . . . . . . . . . . . 4 87 3.1.1. IPv4 Address . . . . . . . . . . . . . . . . . . . . 4 88 3.1.2. IPv6 Address . . . . . . . . . . . . . . . . . . . . 5 89 3.1.3. Hostname . . . . . . . . . . . . . . . . . . . . . . 5 90 3.1.4. AssettID . . . . . . . . . . . . . . . . . . . . . . 6 91 3.1.5. MACAddress . . . . . . . . . . . . . . . . . . . . . 6 92 3.1.6. Timestamp . . . . . . . . . . . . . . . . . . . . . . 6 93 3.1.7. Action . . . . . . . . . . . . . . . . . . . . . . . 7 94 3.1.8. Action Parameters . . . . . . . . . . . . . . . . . . 7 95 3.1.9. AdditionalDataType . . . . . . . . . . . . . . . . . 7 96 3.1.10. AdditionalData . . . . . . . . . . . . . . . . . . . 8 97 3.1.11. Extra . . . . . . . . . . . . . . . . . . . . . . . . 8 98 4. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 101 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 102 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 105 1. Introduction 107 The set of elements which are desired to standarize are the subset of 108 data elements used within the SACM standards and related standards. 109 To this end, the core capability to reasonably identify a network end 110 point and minimally describe an event along with enough information 111 that two parties involved in the communication may determine a way 112 forward for further information exchange. The minimal set of 113 activity and endpoint identifiers will allow parties participating in 114 SACM communications to effectively search their respecitive data 115 stores for relevent and related information and respond to queries or 116 accept events in kind. 118 This information model is intended to describe a minimal number of 119 elements which enable this functionality, but also sufficiently 120 describe the attributes which can define those elements. This 121 combination of information intends to provide enough meta information 122 about information elements to allow both in protocol definition of 123 types in possible data models as well as clear construction of future 124 standardized element definitions. Conversely, this information model 125 is not attempting to define all possible information elements that 126 need to be exchanged. Many information elements, especially those 127 related to host monitoring, are heavily related to the operating 128 system and related software for proper context - beyond the initial 129 scope of this standard. 131 1.1. Conventions and Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119][RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 140 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 141 WON'T)*" in this document are to interpreted as described in RFC 6919 142 [RFC6919]. 144 2. Minimal Needed Information Elements 146 IP Address, hostname, time/date, SWID/CoSWID ID's, firmware versions, 147 serial number, MAC address, certificate ID 149 3. Information Element Metadata 151 name, basic_data_type, octet_length, data_use_type (label, counter, 152 gauge), description, std/vendor type, structure/composite 154 The following fields are defined in the set of metadata about each 155 information element 157 name: 158 A descriptive but concise name to be used for human understanding 160 basic data type: 161 A fundamental data type supported by the this information model. 162 The predefined types include unsigned integers, signed integers, 163 octet array, string, IP addresses, MAC addresses 165 octet length: 166 The number of octets maximally used for this information 168 data use type: 169 This refines the basic data type expressing the usage of the 170 value. For example, some integers represent mathematical values 171 and may be added together (counts for example) while some things 172 may be expressed as an integer, but are really a type of label 173 (e.g. IP address) 175 description: 176 A longer textual description of this data type 178 registration domain: 179 The domain in which this information element is defined. 181 composite structure: 182 The definition of the composite structure of following elements, 183 e.g. list, set, map 185 3.1. Information Elements 187 3.1.1. IPv4 Address 188 +---------------------+----------------------------------------+ 189 | Field | Value | 190 +---------------------+----------------------------------------+ 191 | Name | IPv4 | 192 | Basic data type | 32-bit unsigned integer | 193 | Octet length | 4 | 194 | Data use type | Label | 195 | Description | An Internet Protocol version 4 address | 196 | Registration domain | standard | 197 | Composite structure | N/A | 198 | Comments | | 199 +---------------------+----------------------------------------+ 201 3.1.2. IPv6 Address 203 +---------------------+----------------------------------------+ 204 | Field | Value | 205 +---------------------+----------------------------------------+ 206 | Name | IPv6 | 207 | Basic data type | octet array | 208 | Octet length | 16 | 209 | Data use type | Label | 210 | Description | An Internet Protocol version 6 address | 211 | Registration domain | standard | 212 | Composite structure | N/A | 213 | Comments | | 214 +---------------------+----------------------------------------+ 216 3.1.3. Hostname 218 +---------------------+---------------------------------------------+ 219 | Field | Value | 220 +---------------------+---------------------------------------------+ 221 | Name | Hostname | 222 | Basic data type | string | 223 | Octet length | up to 256 | 224 | Data use type | Label | 225 | Description | Fully qualified domain name of endpoint | 226 | | system | 227 | Registration domain | standard | 228 | Composite structure | N/A | 229 | Comments | | 230 +---------------------+---------------------------------------------+ 232 3.1.4. AssettID 234 +---------------------+--------------------------+ 235 | Field | Value | 236 +---------------------+--------------------------+ 237 | Name | AssettID | 238 | Basic data type | string | 239 | Octet length | up to 256 | 240 | Data use type | Label | 241 | Description | AssettID of topic assett | 242 | Registration domain | standard | 243 | Composite structure | N/A | 244 | Comments | | 245 +---------------------+--------------------------+ 247 3.1.5. MACAddress 249 +---------------------+---------------------------+ 250 | Field | Value | 251 +---------------------+---------------------------+ 252 | Name | MACAddress | 253 | Basic data type | string | 254 | Octet length | 6 | 255 | Data use type | Label | 256 | Description | IEEE 802 Hardware Address | 257 | Registration domain | standard | 258 | Composite structure | N/A | 259 | Comments | | 260 +---------------------+---------------------------+ 262 3.1.6. Timestamp 264 +---------------------+---------------------------+ 265 | Field | Value | 266 +---------------------+---------------------------+ 267 | Name | timestamp | 268 | Basic data type | ISO time formatted string | 269 | Octet length | variable | 270 | Data use type | time/date | 271 | Description | time date string | 272 | Registration domain | standard | 273 | Composite structure | N/A | 274 | Comments | | 275 +---------------------+---------------------------+ 277 3.1.7. Action 279 +-------------------+-----------------------------------------------+ 280 | Field | Value | 281 +-------------------+-----------------------------------------------+ 282 | Name | Action | 283 | Basic data type | enumeration | 284 | Octet length | 2 | 285 | Data use type | label | 286 | Description | | 287 | Registration | standard | 288 | domain | | 289 | Composite | | 290 | structure | | 291 | Comments | RunAssessment, AssessmentResult, Subscribe, | 292 | | PubEvent, | 293 +-------------------+-----------------------------------------------+ 295 3.1.8. Action Parameters 297 +-----------------+-------------------------------------------------+ 298 | Field | Value | 299 +-----------------+-------------------------------------------------+ 300 | Name | Action Parameters | 301 | Basic data type | list | 302 | Octet length | variable | 303 | Data use type | variable | 304 | Description | parameters for the action command, defined per | 305 | | action command | 306 | Registration | standard | 307 | domain | | 308 | Composite | list | 309 | structure | | 310 | Comments | | 311 +-----------------+-------------------------------------------------+ 313 3.1.9. AdditionalDataType 314 +--------------+----------------------------------------------------+ 315 | Field | Value | 316 +--------------+----------------------------------------------------+ 317 | Name | AdditionalDataType | 318 | Basic data | 16-bit integer | 319 | type | | 320 | Octet length | 2 | 321 | Data use | label | 322 | type | | 323 | Description | An enumeration of registered additional data types | 324 | | that can be contained in the AdditionalData field | 325 | Registration | standard | 326 | domain | | 327 | Composite | N/A | 328 | structure | | 329 | Comments | | 330 +--------------+----------------------------------------------------+ 332 3.1.10. AdditionalData 334 +----------------+--------------------------------------------------+ 335 | Field | Value | 336 +----------------+--------------------------------------------------+ 337 | Name | AdditionalData | 338 | Basic data | octet-array | 339 | type | | 340 | Octet length | variable | 341 | Data use type | opaque | 342 | Description | This is an envelope to contain other | 343 | | standardized data exchange formats | 344 | Registration | standard | 345 | domain | | 346 | Composite | N/A | 347 | structure | | 348 | Comments | formats like OVAL or IF-MAP may be contained in | 349 | | here | 350 +----------------+--------------------------------------------------+ 352 3.1.11. Extra 354 [ed: remove before publication] 355 +---------------------+----------+ 356 | Field | Value | 357 +---------------------+----------+ 358 | Name | | 359 | Basic data type | | 360 | Octet length | | 361 | Data use type | | 362 | Description | | 363 | Registration domain | standard | 364 | Composite structure | | 365 | Comments | | 366 +---------------------+----------+ 368 4. Updates 370 o 25-July-2019 - initial document 372 5. IANA Considerations 374 This will create a IANA registery of elements, eventually. IANA 375 language to be added 377 6. Security Considerations 379 To be completed. 381 7. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 389 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 390 DOI 10.17487/RFC6919, April 2013, 391 . 393 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 394 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 395 May 2017, . 397 Appendix A. Acknowledgements 399 The contributions of the SACM working group have greatly impacted the 400 thinking presented here. In particular, we wish to thank Bill 401 Munyan, Adam Monteville, and Henk Birkholz. 403 Author's Address 405 Christopher Inacio 406 Carnegie Mellon University 407 4500 5th Ave. 408 Pittsburgh PA 15213 409 United States 411 Email: inacio@cert.org