idnits 2.17.1 draft-li-sacm-light-weighted-vul-record-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (November 02, 2020) is 1270 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Automation and Continuous Monitoring J. Li 3 Internet-Draft J. Fu 4 Intended status: Standards Track X. Li 5 Expires: May 6, 2021 Y. Cheng 6 China Mobile 7 November 02, 2020 9 light weithted vul record 10 draft-li-sacm-light-weighted-vul-record-00 12 Abstract 14 Vulnerability information will be recorded in risk detection and 15 scanning. If a vulnerability is detected in a host during one scan, 16 a record will be generated and added to the database, together with a 17 time-stamp when the vulnerability is detected. If risk detection is 18 carried out periodically, a series of records will be generated for 19 each detection, until vulnerability is fixed. At present, a common 20 way to record vulnerabilities is a vulnerability--a detection--a 21 record, a vulnerability--N detections--N records(N>1).In this way, 22 the number of vulnerability records is related to the rounds of 23 detection. In the case that the number of existing vulnerabilities 24 remains unchanged, more frequent vulnerabilities are scanned, more 25 records are recorded In this document, a light weighted vulnerability 26 recording method is proposed. To make that, in the whole life cycle 27 of a vulnerability, only one record is generated after multiple 28 detections. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119][RFC8174]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 6, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Data Structure . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Normative References . . . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 In the process of risk management, large enterprises and institutions 78 often use the method of periodic vulnerability detection and 79 scanning. At present, the common way to record vulnerabilities is to 80 keep many records for each vulnerability. Since the vulnerability 81 state is time-dependent, each vulnerability record will carry time 82 information to indicate the time stamp when the vulnerability is 83 detected. A vulnerability record usually contain the following 84 elements: 86 1.IP address 88 2.port: e.g. 23 90 3.service: e.g. telnet 92 4.protocol: TCP or UDP 94 5.vul_name: e.g. telnet weak password 95 6.vul_det_time: time stamp when the vulnerability is detected, e.g. 96 2020-10-10 10:20:30 98 7.vul_detail: additional information of vulnerability, in the 99 scenario of weak password, vul_detail could be admin / 123456 101 By using these data, security administrators can locate the 102 vulnerabilities on specific hosts and specific services. 104 2. Data Structure 106 In the work of continuous security monitoring, if the same 107 vulnerability of the same host is not repaired in time, multiple 108 records will be generated. And the more frequent periodic detection, 109 the more vulnerability records will be generated. Repeated 110 vulnerability records will waste storage space and increase the cost 111 of data analysis. This draft proposes a light weighted vulnerability 112 recording method, which stores only one record for the same 113 vulnerability of the same host. By optimizing the structure of data, 114 a record contains a relatively rich life process of vulnerabilities. 116 Light weighted vulnerability record defined in this document contains 117 the following elements: 119 IP, port, service, protocol, vul_name, vul_status, vul_det_time, 120 vul_update_time, vul_fix_time, vul_detail. 122 Compared with the vulnerability record above, the light weighted 123 vulnerability record adds 3 elements: 125 1.vul_status: show the vulnerability is currently existing or fixed. 126 0 indicates that the vulnerability has been fixed, and 1 indicates 127 that the vulnerability exists. For those vulnerabilities detected 128 for the first time, vul_status is 1, and for those previously 129 detected but currently fixed vulnerabilities, vul_status is 0 131 2.vul_det_time: time stamp that detect the vulnerability first time. 132 3. Vulnerability repair time: when a vulnerability is found to have 133 been fixed during a certain detection, the time at that time will be 134 recorded 136 3.vul_fix_time:once it is detected that the vulnerability has been 137 fixed, record this time. 139 Compared with the vulnerability record above, the light weighted 140 vulnerability record re-defined 1 element: 142 1.vul_update_time:last update time of vulnerability status. 143 corresponding to the previous vul_update_time, it has different 144 meaning from the previous one. It represents the latest update time 145 of vulnerability status. When detect many times, the latest time 146 stamp will be recorded to cover the old record. 148 Suppose that a company carried out a round of vulnerability detection 149 every day, and found that there is a telnet weak password on a host 150 from 2020-10-11 to 2020-10-17. And it was fixed on 2020-10-18. One 151 vulnerability record generated everyday. Records were as follows: 153 { 155 IP:A.B.C.D, 157 port:23, 159 service:telnet, 161 protocol:TCP, 163 vul_name:telnet weak password, 165 vul_detect_time:2020-10-11 10:20:30, 167 vul_detail:admin/123456 169 } 171 {Records for 2020-10-12} 173 {Records for 2020-10-13} 175 {Records for 2020-10-14} 177 {Records for 2020-10-15} 179 {Records for 2020-10-16} 181 { 183 IP:A.B.C.D, 185 port:23, 187 service:telnet, 189 protocol:TCP, 190 vul_name:telnet weak password, 192 vul_detect_time:2020-10-17 10:20:30, 194 vul_detail:admin/123456 196 } 198 On 2020-10-18, no more records for this vulnerability, since it was 199 fixed. 201 By using light weighted vul record mentioned in this document, this 202 telnet weak password generated only one record. On 2020-10-17, 203 record was as follow: 205 { 207 IP:A.B.C.D, 209 port:23, 211 service:telnet, 213 protocol:TCP, 215 vul_name:telnet weak password, 217 vul_status:0, 219 vul_det_time:2020-10-11 10:20:30, 221 vul_update_time:2020-10-17 10:20:30, 223 vul_fix_time:2020-10-17 10:20:30, 225 vul_detail:admin/123456 227 } 229 On 2020-10-18, record was as follow: 231 { 233 IP:A.B.C.D, 235 port:23, 237 service:telnet, 238 protocol:TCP, 240 vul_name:telnet weak password, 242 vul_status:0, 244 vul_det_time:2020-10-11 10:20:30, 246 vul_update_time:2020-10-18 10:20:30, 248 vul_fix_time:2020-10-18 10:20:30, 250 vul_detail:null 252 } 254 3. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 262 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 263 May 2017, . 265 Authors' Addresses 267 Jiang Li 268 China Mobile 269 Beijing 100053 270 China 272 Email: lijiang@chinamobile.com 274 Jun Fu 275 China Mobile 276 Beijing 100053 277 China 279 Email: fujun@chinamobile.com 280 Xiaoxiao Li 281 China Mobile 282 Beijing 100053 283 China 285 Email: lixiaoxiao@chinamobile.com 287 Yexia Cheng 288 China Mobile 289 Beijing 100053 290 China 292 Email: chengyexia@chinamobile.com