[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Security Automation and Continuous Monitoring                      J. Li
Internet-Draft                                                     J. Fu
Intended status: Standards Track                                   X. Li
Expires: May 6, 2021                                            Y. Cheng
                                                            China Mobile
                                                       November 02, 2020


                       light weithted vul record
               draft-li-sacm-light-weighted-vul-record-00

Abstract

   Vulnerability information will be recorded in risk detection and
   scanning.  If a vulnerability is detected in a host during one scan,
   a record will be generated and added to the database, together with a
   time-stamp when the vulnerability is detected.  If risk detection is
   carried out periodically, a series of records will be generated for
   each detection, until vulnerability is fixed.  At present, a common
   way to record vulnerabilities is a vulnerability--a detection--a
   record, a vulnerability--N detections--N records(N>1).In this way,
   the number of vulnerability records is related to the rounds of
   detection.  In the case that the number of existing vulnerabilities
   remains unchanged, more frequent vulnerabilities are scanned, more
   records are recorded In this document, a light weighted vulnerability
   recording method is proposed.  To make that, in the whole life cycle
   of a vulnerability, only one record is generated after multiple
   detections.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119][RFC8174].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any




Li, et al.                 Expires May 6, 2021                  [Page 1]


Internet-Draft          light weithted vul record          November 2020


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 6, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Data Structure  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In the process of risk management, large enterprises and institutions
   often use the method of periodic vulnerability detection and
   scanning.  At present, the common way to record vulnerabilities is to
   keep many records for each vulnerability.  Since the vulnerability
   state is time-dependent, each vulnerability record will carry time
   information to indicate the time stamp when the vulnerability is
   detected.  A vulnerability record usually contain the following
   elements:

   1.IP address

   2.port: e.g. 23

   3.service: e.g. telnet

   4.protocol: TCP or UDP

   5.vul_name: e.g. telnet weak password




Li, et al.                 Expires May 6, 2021                  [Page 2]


Internet-Draft          light weithted vul record          November 2020


   6.vul_det_time: time stamp when the vulnerability is detected, e.g.
   2020-10-10 10:20:30

   7.vul_detail: additional information of vulnerability, in the
   scenario of weak password, vul_detail could be admin / 123456

   By using these data, security administrators can locate the
   vulnerabilities on specific hosts and specific services.

2.  Data Structure

   In the work of continuous security monitoring, if the same
   vulnerability of the same host is not repaired in time, multiple
   records will be generated.  And the more frequent periodic detection,
   the more vulnerability records will be generated.  Repeated
   vulnerability records will waste storage space and increase the cost
   of data analysis.  This draft proposes a light weighted vulnerability
   recording method, which stores only one record for the same
   vulnerability of the same host.  By optimizing the structure of data,
   a record contains a relatively rich life process of vulnerabilities.

   Light weighted vulnerability record defined in this document contains
   the following elements:

   IP, port, service, protocol, vul_name, vul_status, vul_det_time,
   vul_update_time, vul_fix_time, vul_detail.

   Compared with the vulnerability record above, the light weighted
   vulnerability record adds 3 elements:

   1.vul_status: show the vulnerability is currently existing or fixed.
   0 indicates that the vulnerability has been fixed, and 1 indicates
   that the vulnerability exists.  For those vulnerabilities detected
   for the first time, vul_status is 1, and for those previously
   detected but currently fixed vulnerabilities, vul_status is 0

   2.vul_det_time: time stamp that detect the vulnerability first time.
   3.  Vulnerability repair time: when a vulnerability is found to have
   been fixed during a certain detection, the time at that time will be
   recorded

   3.vul_fix_time:once it is detected that the vulnerability has been
   fixed, record this time.

   Compared with the vulnerability record above, the light weighted
   vulnerability record re-defined 1 element:





Li, et al.                 Expires May 6, 2021                  [Page 3]


Internet-Draft          light weithted vul record          November 2020


   1.vul_update_time:last update time of vulnerability status.
   corresponding to the previous vul_update_time, it has different
   meaning from the previous one.  It represents the latest update time
   of vulnerability status.  When detect many times, the latest time
   stamp will be recorded to cover the old record.

   Suppose that a company carried out a round of vulnerability detection
   every day, and found that there is a telnet weak password on a host
   from 2020-10-11 to 2020-10-17.  And it was fixed on 2020-10-18.  One
   vulnerability record generated everyday.  Records were as follows:

   {

   IP:A.B.C.D,

   port:23,

   service:telnet,

   protocol:TCP,

   vul_name:telnet weak password,

   vul_detect_time:2020-10-11 10:20:30,

   vul_detail:admin/123456

   }

   {Records for 2020-10-12}

   {Records for 2020-10-13}

   {Records for 2020-10-14}

   {Records for 2020-10-15}

   {Records for 2020-10-16}

   {

   IP:A.B.C.D,

   port:23,

   service:telnet,

   protocol:TCP,



Li, et al.                 Expires May 6, 2021                  [Page 4]


Internet-Draft          light weithted vul record          November 2020


   vul_name:telnet weak password,

   vul_detect_time:2020-10-17 10:20:30,

   vul_detail:admin/123456

   }

   On 2020-10-18, no more records for this vulnerability, since it was
   fixed.

   By using light weighted vul record mentioned in this document, this
   telnet weak password generated only one record.  On 2020-10-17,
   record was as follow:

   {

   IP:A.B.C.D,

   port:23,

   service:telnet,

   protocol:TCP,

   vul_name:telnet weak password,

   vul_status:0,

   vul_det_time:2020-10-11 10:20:30,

   vul_update_time:2020-10-17 10:20:30,

   vul_fix_time:2020-10-17 10:20:30,

   vul_detail:admin/123456

   }

   On 2020-10-18, record was as follow:

   {

   IP:A.B.C.D,

   port:23,

   service:telnet,



Li, et al.                 Expires May 6, 2021                  [Page 5]


Internet-Draft          light weithted vul record          November 2020


   protocol:TCP,

   vul_name:telnet weak password,

   vul_status:0,

   vul_det_time:2020-10-11 10:20:30,

   vul_update_time:2020-10-18 10:20:30,

   vul_fix_time:2020-10-18 10:20:30,

   vul_detail:null

   }

3.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Jiang Li
   China Mobile
   Beijing  100053
   China

   Email: lijiang@chinamobile.com


   Jun Fu
   China Mobile
   Beijing  100053
   China

   Email: fujun@chinamobile.com








Li, et al.                 Expires May 6, 2021                  [Page 6]


Internet-Draft          light weithted vul record          November 2020


   Xiaoxiao Li
   China Mobile
   Beijing  100053
   China

   Email: lixiaoxiao@chinamobile.com


   Yexia Cheng
   China Mobile
   Beijing  100053
   China

   Email: chengyexia@chinamobile.com





































Li, et al.                 Expires May 6, 2021                  [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/