CVE IDs for malware

Author: Kurt Seifried-2 (08-17-2020)

My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).

On Mon, Aug 17, 2020 at 11:58 AM Art Manion <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Art Manion (08-17-2020)

My recollection, real or imagined, is that it just wasn't a strong use case among CVE consumers. I don't recall if there were active reasons against, like possibly aiding malware developers/users.

I think it's good for the CVE Project be separate from any pre-public-disclosure issues (embargo length, coordination issues, malware/goodware, vulnerability equities, etc). When a vulnerability becomes public, it gets a CVE ID, what happens before or after the CVE ID issuance is other peoples' problems.

Pretty sure CVE documentation prefers/recommends/suggests coordinated vulnerability disclosure, but does not require it.

- Art

On 2020-08-17 14:48, Kurt Seifried wrote:
> My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).
>
>
>
>
> On Mon, Aug 17, 2020 at 11:58 AM Art Manion < <mailto:>> wrote:
>
> Two threads based on this story:
>
> https://www.zdnet.com/article/for-six-months-security-researchers-have-secretly-distributed-an-emotet-vaccine-across-the-world/
>
> https://zdnet1.cbsistatic.com/hub/i/2020/08/14/e3a34948-ef00-496f-893c-709f8f748899/emotet-trolling.png
>
> 1. My opinion is that CVE identifies vulns, period. CVE should be agnostic about the type or use of the software. E.g., one person's lawful intercept software is someone else's malware, and the CVE Project should not be delving into the relative attacker/defender perspective. I don't consider this a high priority work item for the Project.
>
> 2. I believe the assignment rules have changed, as part of the recent CNA rules update. The screen shot in the ZDNet story mentions INC4 which I believe is deprecated?
>
> Current rules do not mention INC4 or malware:
>
> https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules
> https://cve.mitre.org/cve/cna/CNA_Rules_v3.0.pdf
>
> Deprecated rules, but still published, do mention INC4 and malware:
>
> https://cve.mitre.org/cve/editorial_policies/counting_rules.html
> https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf
>
> Regards,
>
> - Art
>
>
>
> --
> Kurt Seifried
> <mailto:> ... [show rest of quote]

Author: Landfield (08-17-2020)

In reply to this post by Kurt Seifried-2

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Different things with different needs. CVE is a focused effort targeted toward providing a means to identify software vulnerabilities and software vulnerabilities only. MITRE has MAEC - Malware Attribute Enumeration and Characterization ... which is focused just on malware. Not a registry but.... MITRE did try to get one started once but none of the vendors at the time seemed to care to have someone else providing naming, getting in the middle of the response process and literally slowing things down. There also did not seem to be any real demand for it in the federal or consumer space as well.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Kurt Seifried <>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).

On Mon, Aug 17, 2020 at 11:58 AM Art Manion <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Scott Lawler (08-17-2020)

As one of those dinosaurs, I agree with Kent. I don't think we should spend brain cells on malware.

It's possible that the demand may ramp up at a later date and we could resurrect a son-of-MAEC.

But, at this time, we should stay the course and focus on doing the best we can with our currently defined CVE scope.

Thank you,

Scott

703-509-9330

For Cyber Emergencies email:

From: "Landfield, Kent" <>
Date: Monday, August 17, 2020 at 3:10 PM
To: Kurt Seifried <>, Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: [EXTERNAL] Re: CVE IDs for malware

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Different things with different needs. CVE is a focused effort targeted toward providing a means to identify software vulnerabilities and software vulnerabilities only. MITRE has MAEC - Malware Attribute Enumeration and Characterization ... which is focused just on malware. Not a registry but.... MITRE did try to get one started once but none of the vendors at the time seemed to care to have someone else providing naming, getting in the middle of the response process and literally slowing things down. There also did not seem to be any real demand for it in the federal or consumer space as well.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Kurt Seifried <>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).

On Mon, Aug 17, 2020 at 11:58 AM Art Manion <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Art Manion (08-17-2020)

As I wrote,

> I don't consider this a high priority work item for the Project.

Happy to consider it in the future if demand shifts.

I'm still curious about INC4 and the new/old rules both being public and any confusion that is causing. Depending on the answer, malware could be interpreted as in-scope for the current rules. More importantly, we should be clear about which set of rules is current. (I acknowledge that I may be the only one who is confused).

- Art

On 2020-08-17 15:16, Scott Lawler wrote:
> As one of those dinosaurs, I agree with Kent. I don't think we should spend brain cells on malware.
>
>
>
> It's possible that the demand may ramp up at a later date and we could resurrect a son-of-MAEC.
>
>
>
> But, at this time, we should stay the course and focus on doing the best we can with our currently defined CVE scope.
>
>
>
> Thank you,
>
> Scott
>
>
>
> 703-509-9330
>
>
>
> For Cyber Emergencies email: <mailto:>
>
>
>
>
>
> *From: *"Landfield, Kent" <>
> *Date: *Monday, August 17, 2020 at 3:10 PM
> *To: *Kurt Seifried <>, Art Manion <>
> *Cc: *CVE Editorial Board Discussion <>
> *Subject: *[EXTERNAL] Re: CVE IDs for malware
>
>
>
>
> This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....
>
>
> Different things with different needs. CVE is a focused effort targeted toward providing a means to identify software vulnerabilities and software vulnerabilities only. MITRE has MAEC - Malware Attribute Enumeration and Characterization ... < https://maecproject.github.io/ > which is focused just on malware. Not a registry but.... MITRE did try to get one started once but none of the vendors at the time seemed to care to have someone else providing naming, getting in the middle of the response process and literally slowing things down. There also did not seem to be any real demand for it in the federal or consumer space as well.
>
> Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!
>
> --
>
> Kent Landfield
>
> +1.817.637.8026
>
> <mailto:>
>
>
>
>
>
> *From: *Kurt Seifried <>
> *Date: *Monday, August 17, 2020 at 1:49 PM
> *To: *Art Manion <>
> *Cc: *CVE Editorial Board Discussion <>
> *Subject: *Re: CVE IDs for malware
>
>
>
> My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).
>
>
>
>
>
> On Mon, Aug 17, 2020 at 11:58 AM Art Manion < <mailto:>> wrote:
>
> Two threads based on this story:
>
> https://www.zdnet.com/article/for-six-months-security-researchers-have-secretly-distributed-an-emotet-vaccine-across-the-world/
>
> https://zdnet1.cbsistatic.com/hub/i/2020/08/14/e3a34948-ef00-496f-893c-709f8f748899/emotet-trolling.png
>
> 1. My opinion is that CVE identifies vulns, period. CVE should be agnostic about the type or use of the software. E.g., one person's lawful intercept software is someone else's malware, and the CVE Project should not be delving into the relative attacker/defender perspective. I don't consider this a high priority work item for the Project.
>
> 2. I believe the assignment rules have changed, as part of the recent CNA rules update. The screen shot in the ZDNet story mentions INC4 which I believe is deprecated?
>
> Current rules do not mention INC4 or malware:
>
> https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules
> https://cve.mitre.org/cve/cna/CNA_Rules_v3.0.pdf
>
> Deprecated rules, but still published, do mention INC4 and malware:
>
> https://cve.mitre.org/cve/editorial_policies/counting_rules.html
> https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf
>
> Regards,
>
> - Art
>
>
>
>
> --
>
> Kurt Seifried
> <mailto:>
> ... [show rest of quote]

Author: Landfield (08-17-2020)

This was apparently changed in the last set of "CNA Rules" and not really well communicated. Yes, they were in the rules document but the change and the needed mappings to the new rules did not get socialized. At least from my perspective. The SPWG is in the process of doing a full review of the "CNA Rules" document. There is a great deal that needs to change.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!
--
Kent Landfield
+1.817.637.8026

On 8/17/20, 2:40 PM, "Art Manion" <> wrote:

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

As I wrote,

> I don't consider this a high priority work item for the Project.

Happy to consider it in the future if demand shifts.

I'm still curious about INC4 and the new/old rules both being public and any confusion that is causing. Depending on the answer, malware could be interpreted as in-scope for the current rules. More importantly, we should be clear about which set of rules is current. (I acknowledge that I may be the only one who is confused).

- Art

On 2020-08-17 15:16, Scott Lawler wrote:
> As one of those dinosaurs, I agree with Kent. I don't think we should spend brain cells on malware.
>
>
>
> It's possible that the demand may ramp up at a later date and we could resurrect a son-of-MAEC.
>
>
>
> But, at this time, we should stay the course and focus on doing the best we can with our currently defined CVE scope.
>
>
>
> Thank you,
>
> Scott
>
>
>
> 703-509-9330
>
>
>
> For Cyber Emergencies email: <mailto:>
>
>
>
>
>
> *From: *"Landfield, Kent" <>
> *Date: *Monday, August 17, 2020 at 3:10 PM
> *To: *Kurt Seifried <>, Art Manion <>
> *Cc: *CVE Editorial Board Discussion <>
> *Subject: *[EXTERNAL] Re: CVE IDs for malware
>
>
>
>
> This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....
>
>
> Different things with different needs. CVE is a focused effort targeted toward providing a means to identify software vulnerabilities and software vulnerabilities only. MITRE has MAEC - Malware Attribute Enumeration and Characterization ... < https://maecproject.github.io/ > which is focused just on malware. Not a registry but.... MITRE did try to get one started once but none of the vendors at the time seemed to care to have someone else providing naming, getting in the middle of the response process and literally slowing things down. There also did not seem to be any real demand for it in the federal or consumer space as well.
>
> Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!
>
> --
>
> Kent Landfield
>
> +1.817.637.8026
>
> <mailto:>
>
>
>
>
>
> *From: *Kurt Seifried <>
> *Date: *Monday, August 17, 2020 at 1:49 PM
> *To: *Art Manion <>
> *Cc: *CVE Editorial Board Discussion <>
> *Subject: *Re: CVE IDs for malware
>
>
>
> My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).
>
>
>
>
>
> On Mon, Aug 17, 2020 at 11:58 AM Art Manion < <mailto:>> wrote:
>
> Two threads based on this story:
>
> https://www.zdnet.com/article/for-six-months-security-researchers-have-secretly-distributed-an-emotet-vaccine-across-the-world/
>
> https://zdnet1.cbsistatic.com/hub/i/2020/08/14/e3a34948-ef00-496f-893c-709f8f748899/emotet-trolling.png
>
> 1. My opinion is that CVE identifies vulns, period. CVE should be agnostic about the type or use of the software. E.g., one person's lawful intercept software is someone else's malware, and the CVE Project should not be delving into the relative attacker/defender perspective. I don't consider this a high priority work item for the Project.
>
> 2. I believe the assignment rules have changed, as part of the recent CNA rules update. The screen shot in the ZDNet story mentions INC4 which I believe is deprecated?
>
> Current rules do not mention INC4 or malware:
>
> https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules
> https://cve.mitre.org/cve/cna/CNA_Rules_v3.0.pdf
>
> Deprecated rules, but still published, do mention INC4 and malware:
>
> https://cve.mitre.org/cve/editorial_policies/counting_rules.html
> https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf
>
> Regards,
>
> - Art
>
>
>
>
> --
>
> Kurt Seifried
> <mailto:>
>

Author: 5 posts (08-17-2020)

My opinion: This is an issue of usefulness and coverage priority, not theoretical definitions. While it is true that malware is software, and cve identifies vulnerabilities in software, therefore in theory CVE does have an opportunity to enumerate vulnerabilities within malware software families: this is not to my knowledge useful to the community we serve. (if it does become valuable, then we should reconsider). The fact of the matter is that we cannot yet provide 100% coverage over the body of software that _is_ useful to the community so zero cycles should be spent on coverage where there is no utility.

--tk

On Mon, Aug 17, 2020 at 12:58 PM Art Manion <> wrote:

... [show rest of quote]

--

Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

Author: Landfield (08-17-2020)

Agreed. But while malware is software, malware USES vulnerabilities that some portion of already have CVEs identified. A large swath of malware relies of two, three or four year-old (or older) vulnerabilities since folks keep putting up systems and not patching. PATCH PEOPLE! I really am not interested in helping malicious actors improve their software. 😉

Now if we could get researchers to identify the CVEs and vulnerabilities used in publish malware tools and libraries, and publish that, we could really pressure folks to at least patch those.... Just a thought.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Tim Keanini <>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

CAUTION : External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

My opinion: This is an issue of usefulness and coverage priority, not theoretical definitions. While it is true that malware is software, and cve identifies vulnerabilities in software, therefore in theory CVE does have an opportunity to enumerate vulnerabilities within malware software families: this is not to my knowledge useful to the community we serve. (if it does become valuable, then we should reconsider). The fact of the matter is that we cannot yet provide 100% coverage over the body of software that _is_ useful to the community so zero cycles should be spent on coverage where there is no utility.

--tk

On Mon, Aug 17, 2020 at 12:58 PM Art Manion <> wrote:

... [show rest of quote]

--

Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

Author: Waltermire (08-17-2020)

In reply to this post by Scott Lawler

Art mentioned that assigning the label "malware" to software/hardware is often in the eye of the beholder. Spyware is a type of malware. I would guess that CVE has probably assigned a CVE ID to software that can be classified as “spyware” in the past. This makes me think that there is no clean way to completely separate the set of software/hardware that is “malware” from the set that is not. This means we will end up assigning vulns for some segment of software/hardware that falls in the grey area in the middle.

It's also important to not conflate what CVE and MAEC do. CVE identifies vulnerabilities and associated metadata for hardware, software, and services. MAEC was intended to characterize information related to malware research and behavior. CVE and MAEK do not just differ in their subjects, they differ completely in their methodology.

Given the current CNA rules, I believe a strong argument could be made that a CVE should be assigned for software that is considered malware. It is not explicitly disallowed. Furthermore, it is not the CVE Program's responsibility to determine if a piece of software is or is not malware. If we refuse to assign a CVE on the basis that the subject is malware, we are making this determination. This also means that some CVE ID assigners need to spend some brain cells on the topic. This is unavoidable, but at the moment there is no guidance to help them move forward.

IMHO, the easiest way to avoid spending brain cells on this topic is to not consider if software is malware or not. The CVE program should simply assign a CVE ID if a legitimate vulnerability needs to be identified and let others figure out if the target software is malware or not.

Dave

From: Scott Lawler <>
Sent: Monday, August 17, 2020 3:16 PM
To: CVE Editorial Board Discussion <>
Subject: Re: [EXTERNAL] Re: CVE IDs for malware

As one of those dinosaurs, I agree with Kent. I don't think we should spend brain cells on malware.

It's possible that the demand may ramp up at a later date and we could resurrect a son-of-MAEC.

But, at this time, we should stay the course and focus on doing the best we can with our currently defined CVE scope.

Thank you,

Scott

703-509-9330

For Cyber Emergencies email:

From: "Landfield, Kent" <>
Date: Monday, August 17, 2020 at 3:10 PM
To: Kurt Seifried <>, Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: [EXTERNAL] Re: CVE IDs for malware

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Different things with different needs. CVE is a focused effort targeted toward providing a means to identify software vulnerabilities and software vulnerabilities only. MITRE has MAEC - Malware Attribute Enumeration and Characterization ... which is focused just on malware. Not a registry but.... MITRE did try to get one started once but none of the vendors at the time seemed to care to have someone else providing naming, getting in the middle of the response process and literally slowing things down. There also did not seem to be any real demand for it in the federal or consumer space as well.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Kurt Seifried <>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).

On Mon, Aug 17, 2020 at 11:58 AM Art Manion <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Kurt Seifried-2 (08-17-2020)

One comment:

We won't know if the market wants this, right now we've been telling them to go away, so many don't try (I encountered this in Open Source, huge numbers of devs thought getting a CVE was too complicated so they never bothered). One aspect would be to do some of these to show 1) it's possible and 2) not very hard, for all we know there are lots of people wanting CVEs for this use case.

I would suggest giving them the CVE for this vuln and see what happens. If the flood gates open, well, then the market has spoken has it not?

On Mon, Aug 17, 2020 at 2:11 PM Landfield, Kent <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Landfield (08-17-2020)

I will echo what has already been stated here a few times today. CVE does not do malware. If there is a need, go form that somewhere else.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Kurt Seifried <>
Date: Monday, August 17, 2020 at 3:27 PM
To: Kent Landfield <>
Cc: Tim Keanini <>, Art Manion <>, CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

CAUTION : External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

One comment:

We won't know if the market wants this, right now we've been telling them to go away, so many don't try (I encountered this in Open Source, huge numbers of devs thought getting a CVE was too complicated so they never bothered). One aspect would be to do some of these to show 1) it's possible and 2) not very hard, for all we know there are lots of people wanting CVEs for this use case.

I would suggest giving them the CVE for this vuln and see what happens. If the flood gates open, well, then the market has spoken has it not?

On Mon, Aug 17, 2020 at 2:11 PM Landfield, Kent <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Scott Lawler (08-17-2020)

In reply to this post by Waltermire, David A.

Concur!

Thank you,

Scott

703-509-9330

For Cyber Emergencies email:

From: "Waltermire, David A. (Fed)" <>
Date: Monday, August 17, 2020 at 4:12 PM
To: S Lawler <>, CVE Editorial Board Discussion <>
Subject: RE: [EXTERNAL] Re: CVE IDs for malware

Art mentioned that assigning the label "malware" to software/hardware is often in the eye of the beholder. Spyware is a type of malware. I would guess that CVE has probably assigned a CVE ID to software that can be classified as “spyware” in the past. This makes me think that there is no clean way to completely separate the set of software/hardware that is “malware” from the set that is not. This means we will end up assigning vulns for some segment of software/hardware that falls in the grey area in the middle.

It's also important to not conflate what CVE and MAEC do. CVE identifies vulnerabilities and associated metadata for hardware, software, and services. MAEC was intended to characterize information related to malware research and behavior. CVE and MAEK do not just differ in their subjects, they differ completely in their methodology.

Given the current CNA rules, I believe a strong argument could be made that a CVE should be assigned for software that is considered malware. It is not explicitly disallowed. Furthermore, it is not the CVE Program's responsibility to determine if a piece of software is or is not malware. If we refuse to assign a CVE on the basis that the subject is malware, we are making this determination. This also means that some CVE ID assigners need to spend some brain cells on the topic. This is unavoidable, but at the moment there is no guidance to help them move forward.

IMHO, the easiest way to avoid spending brain cells on this topic is to not consider if software is malware or not. The CVE program should simply assign a CVE ID if a legitimate vulnerability needs to be identified and let others figure out if the target software is malware or not.

Dave

From: Scott Lawler <>
Sent: Monday, August 17, 2020 3:16 PM
To: CVE Editorial Board Discussion <>
Subject: Re: [EXTERNAL] Re: CVE IDs for malware

As one of those dinosaurs, I agree with Kent. I don't think we should spend brain cells on malware.

It's possible that the demand may ramp up at a later date and we could resurrect a son-of-MAEC.

But, at this time, we should stay the course and focus on doing the best we can with our currently defined CVE scope.

Thank you,

Scott

703-509-9330

For Cyber Emergencies email:

From: "Landfield, Kent" <>
Date: Monday, August 17, 2020 at 3:10 PM
To: Kurt Seifried <>, Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: [EXTERNAL] Re: CVE IDs for malware

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Different things with different needs. CVE is a focused effort targeted toward providing a means to identify software vulnerabilities and software vulnerabilities only. MITRE has MAEC - Malware Attribute Enumeration and Characterization ... which is focused just on malware. Not a registry but.... MITRE did try to get one started once but none of the vendors at the time seemed to care to have someone else providing naming, getting in the middle of the response process and literally slowing things down. There also did not seem to be any real demand for it in the federal or consumer space as well.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Kurt Seifried <>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).

On Mon, Aug 17, 2020 at 11:58 AM Art Manion <> wrote:

... [show rest of quote]

--

Kurt Seifried

Author: Waltermire (08-17-2020)

In reply to this post by Landfield, Kent

What about attack tools used (mostly) by the good guys?

There are at least 11 CVE IDs assigned to Metasploit. I am not suggesting that Metasploit is malware, but it could be used that way by someone with bad intentions. There are lots of similar tools that are in this grey area.

Should we stop assigning CVE IDs for these products because they could be considered malware if not ethically used? Of course the answer is "no", because we choose to support pen test tools.

We have to choose to be permissive by some measure (which would need to be defined), or we need to be restrictive. We can't have it both ways. I personally like the option of allowing the assigner to choose if there is value in assigning for software that could be considered malware. This is essentially what we have today in the CNA rules. If the market drives assignment in this way, then no change is needed.

+1 on Kent's idea of open sourcing information on CVE IDs supported by malware tools and libraries. This could help organization to prioritize patching. We should talk more about how to make this happen.

Dave

From: Landfield, Kent <>
Sent: Monday, August 17, 2020 4:10 PM
To: tk blast <>; Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

Agreed. But while malware is software, malware USES vulnerabilities that some portion of already have CVEs identified. A large swath of malware relies of two, three or four year-old (or older) vulnerabilities since folks keep putting up systems and not patching. PATCH PEOPLE! I really am not interested in helping malicious actors improve their software. 😉

Now if we could get researchers to identify the CVEs and vulnerabilities used in publish malware tools and libraries, and publish that, we could really pressure folks to at least patch those.... Just a thought.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Tim Keanini <>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

CAUTION : External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

My opinion: This is an issue of usefulness and coverage priority, not theoretical definitions. While it is true that malware is software, and cve identifies vulnerabilities in software, therefore in theory CVE does have an opportunity to enumerate vulnerabilities within malware software families: this is not to my knowledge useful to the community we serve. (if it does become valuable, then we should reconsider). The fact of the matter is that we cannot yet provide 100% coverage over the body of software that _is_ useful to the community so zero cycles should be spent on coverage where there is no utility.

--tk

On Mon, Aug 17, 2020 at 12:58 PM Art Manion <> wrote:

... [show rest of quote]

--

Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

Author: Beverly Miller (08-24-2020)

Does this discussion have anything to do with the issue written up here?

Dark Reading https://www.darkreading.com/application-security/next-gen-supply-chain-attacks-surge-430-/d/d-id/1338717

While we do pentesting, we also depend heavily on scanning software and CVEs.

Would the concerns cited in the article likely be assigned CVEs? If not, why not?

***See the latest Security Advisory updates here ***

Beverly Alvarez Principal Program ManagerProduct Security Office	919-294-5873
Lenovo.com Twitter \| Instagram \| Facebook \| Linkedin \| YouTube \| Privacy

From: Waltermire, David A. (Fed) <>
Sent: Monday, August 17, 2020 11:41 PM
To: Landfield, Kent <>; tk blast <>; Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: [External] RE: CVE IDs for malware

What about attack tools used (mostly) by the good guys?

There are at least 11 CVE IDs assigned to Metasploit. I am not suggesting that Metasploit is malware, but it could be used that way by someone with bad intentions. There are lots of similar tools that are in this grey area.

Should we stop assigning CVE IDs for these products because they could be considered malware if not ethically used? Of course the answer is "no", because we choose to support pen test tools.

We have to choose to be permissive by some measure (which would need to be defined), or we need to be restrictive. We can't have it both ways. I personally like the option of allowing the assigner to choose if there is value in assigning for software that could be considered malware. This is essentially what we have today in the CNA rules. If the market drives assignment in this way, then no change is needed.

+1 on Kent's idea of open sourcing information on CVE IDs supported by malware tools and libraries. This could help organization to prioritize patching. We should talk more about how to make this happen.

Dave

From: Landfield, Kent <>
Sent: Monday, August 17, 2020 4:10 PM
To: tk blast <>; Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

Agreed. But while malware is software, malware USES vulnerabilities that some portion of already have CVEs identified. A large swath of malware relies of two, three or four year-old (or older) vulnerabilities since folks keep putting up systems and not patching. PATCH PEOPLE! I really am not interested in helping malicious actors improve their software. 😉

Now if we could get researchers to identify the CVEs and vulnerabilities used in publish malware tools and libraries, and publish that, we could really pressure folks to at least patch those.... Just a thought.

Thank you, Gracias, Grazie, Mahalo, 谢谢, Merci!, Спасибо!, Bedankt,Danke!, ありがとう, धन्यवाद!

--

Kent Landfield

+1.817.637.8026

From: Tim Keanini <>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

CAUTION : External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

My opinion: This is an issue of usefulness and coverage priority, not theoretical definitions. While it is true that malware is software, and cve identifies vulnerabilities in software, therefore in theory CVE does have an opportunity to enumerate vulnerabilities within malware software families: this is not to my knowledge useful to the community we serve. (if it does become valuable, then we should reconsider). The fact of the matter is that we cannot yet provide 100% coverage over the body of software that _is_ useful to the community so zero cycles should be spent on coverage where there is no utility.

--tk

On Mon, Aug 17, 2020 at 12:58 PM Art Manion <> wrote:

... [show rest of quote]

--

Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

Author: Art Manion (01-22-2021)

https://malvuln.com/#about

While not a priority, it should IMO be possible to assign CVE IDs to vulnerabilities in any software, including "malware." Remember, the "mal" prefix can be a matter of perspective.

- Art

On 2020-08-17 14:54, Art Manion wrote:

>
> My recollection, real or imagined, is that it just wasn't a strong use case among CVE consumers. I don't recall if there were active reasons against, like possibly aiding malware developers/users.
>
> I think it's good for the CVE Project be separate from any pre-public-disclosure issues (embargo length, coordination issues, malware/goodware, vulnerability equities, etc). When a vulnerability becomes public, it gets a CVE ID, what happens before or after the CVE ID issuance is other peoples' problems.
>
> Pretty sure CVE documentation prefers/recommends/suggests coordinated vulnerability disclosure, but does not require it.
>
> - Art
>
>
> On 2020-08-17 14:48, Kurt Seifried wrote:
>> My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).
>>
>>
>>
>>
>> On Mon, Aug 17, 2020 at 11:58 AM Art Manion < <mailto:>> wrote:
>>
>> Two threads based on this story:
>>
>> https://www.zdnet.com/article/for-six-months-security-researchers-have-secretly-distributed-an-emotet-vaccine-across-the-world/
>>
>> https://zdnet1.cbsistatic.com/hub/i/2020/08/14/e3a34948-ef00-496f-893c-709f8f748899/emotet-trolling.png
>>
>> 1. My opinion is that CVE identifies vulns, period. CVE should be agnostic about the type or use of the software. E.g., one person's lawful intercept software is someone else's malware, and the CVE Project should not be delving into the relative attacker/defender perspective. I don't consider this a high priority work item for the Project.
>>
>> 2. I believe the assignment rules have changed, as part of the recent CNA rules update. The screen shot in the ZDNet story mentions INC4 which I believe is deprecated?
>>
>> Current rules do not mention INC4 or malware:
>>
>> https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules
>> https://cve.mitre.org/cve/cna/CNA_Rules_v3.0.pdf
>>
>> Deprecated rules, but still published, do mention INC4 and malware:
>>
>> https://cve.mitre.org/cve/editorial_policies/counting_rules.html
>> https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf
>>
>> Regards,
>>
>> - Art
>>
>>
>>
>> --
>> Kurt Seifried
>> <mailto:>
>

... [show rest of quote]

Author: Waltermire (01-25-2021)

I believe we left this with the CVE program choosing not to decide what is "mal" and what is not. This means that if there is a valid request to assign a CVE to software in general, the CVE program would support it either through CNA-based assignment or through a CNA of last resort.

Am I remembering this correctly?

Dave

-----Original Message-----
From: Art Manion <>
Sent: Friday, January 22, 2021 10:52 AM
To: Kurt Seifried <>
Cc: CVE Editorial Board Discussion <>
Subject: Re: CVE IDs for malware

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmalvuln.com%2F%23about&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FIIvJZ9LSGIfUsqQtHhnWP7wLqz0zWBUh6iWVJgew7Q%3D&reserved=0

While not a priority, it should IMO be possible to assign CVE IDs to vulnerabilities in any software, including "malware." Remember, the "mal" prefix can be a matter of perspective.

- Art

On 2020-08-17 14:54, Art Manion wrote:
>
> My recollection, real or imagined, is that it just wasn't a strong use case among CVE consumers. I don't recall if there were active reasons against, like possibly aiding malware developers/users.
>
> I think it's good for the CVE Project be separate from any pre-public-disclosure issues (embargo length, coordination issues, malware/goodware, vulnerability equities, etc). When a vulnerability becomes public, it gets a CVE ID, what happens before or after the CVE ID issuance is other peoples' problems.
>
> Pretty sure CVE documentation prefers/recommends/suggests coordinated vulnerability disclosure, but does not require it.
>
> - Art
>
>
> On 2020-08-17 14:48, Kurt Seifried wrote:
>> My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).
>>
>>
>>
>>
>> On Mon, Aug 17, 2020 at 11:58 AM Art Manion < <mailto:>> wrote:
>>
>> Two threads based on this story:
>>
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.zdnet.com%2Farticle%2Ffor-six-months-security-researchers-have-secretly-distributed-an-emotet-vaccine-across-the-world%2F&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9PddX0yPeVZOHgbAuBFzAbXmJFxAlISd7Sy6X%2FqWa7U%3D&reserved=0
>>
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzdnet1.cbsistatic.com%2Fhub%2Fi%2F2020%2F08%2F14%2Fe3a34948-ef00-496f-893c-709f8f748899%2Femotet-trolling.png&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tTPzRmQaJE5tW27wa%2F9YQVC5x9%2Fug0I6np5JWU2cFVc%3D&reserved=0
>>
>> 1. My opinion is that CVE identifies vulns, period. CVE should be agnostic about the type or use of the software. E.g., one person's lawful intercept software is someone else's malware, and the CVE Project should not be delving into the relative attacker/defender perspective. I don't consider this a high priority work item for the Project.
>>
>> 2. I believe the assignment rules have changed, as part of the recent CNA rules update. The screen shot in the ZDNet story mentions INC4 which I believe is deprecated?
>>
>> Current rules do not mention INC4 or malware:
>>
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2Frules.html%23section_7_assignment_rules&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WwZU%2FdM1FNq2MxKqXrIGU0krHtsAGtsXDVubWc6T%2BY%3D&reserved=0
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2FCNA_Rules_v3.0.pdf&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Oltw2ndGBzF6z9DsZDhXAyJlK4v8QfQRku9Kj1L%2FaHw%3D&reserved=0
>>
>> Deprecated rules, but still published, do mention INC4 and malware:
>>
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Feditorial_policies%2Fcounting_rules.html&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IjIruocFwjWhHehtJVRXZfq8Xr5e9gHfmFWyIZyZnwM%3D&reserved=0
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2FCNA_Rules_v1.1.pdf&data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Rg%2F%2FiLOxonJWJUrAD%2BaTnHvoOenUV6iCIa96Z9oVWnA%3D&reserved=0
>>
>> Regards,
>>
>> - Art
>>
>>
>>
>> --
>> Kurt Seifried
>> <mailto:>
> ... [show rest of quote]

Author: Levendis (01-25-2021)

Based on my recollection, you are remembering this correctly Dave. However, no vote was held and I'm unsure as to how many Board members agree with this position. I agree with the position that we assign for malware unless there is a good argument against doing so.
C
Get Outlook for iOS From: Waltermire, David A. (Fed) <>
Sent: Monday, January 25, 2021 1:51:39 PM
To: Manion, Art <>; Seifried, Kurt <>
Cc: CVE Editorial Board Discussion <>
Subject: RE: CVE IDs for malware

Author: 3 posts (01-25-2021)

We can't afford to arbitrate what is malware and what is not for three major reasons. One is that it's a trap or potential quagmire if you prefer, that could quickly get expensive in all sorts of bad ways. Second, there has been "malware" forcibly installed by a major corporation on their customers' PCs, and any vulnerability created by it would be of great public interest and in legitimate need of a CVE. Third, there's nothing to be gained by the program by denying a CVE to someone who wants to use one, for any publicly known vulnerability.

Just assign a CVE to the vulnerability in any software of interest and be done, don't get dirty and bogged down.

Pascal

On Mon, 25 Jan 2021 19:24:20 +0000
Chris Levendis <> wrote:

> Based on my recollection, you are remembering this correctly Dave. However, no vote was held and I'm unsure as to how many Board members agree with this position. I agree with the position that we assign for malware unless there is a good argument against doing so.
>
> C
>
> Get Outlook for iOS< https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1sRHtido$ >
> ________________________________
> From: Waltermire, David A. (Fed) <>
> Sent: Monday, January 25, 2021 1:51:39 PM
> To: Manion, Art <>; Seifried, Kurt <>
> Cc: CVE Editorial Board Discussion <>
> Subject: RE: CVE IDs for malware
>
> I believe we left this with the CVE program choosing not to decide what is "mal" and what is not. This means that if there is a valid request to assign a CVE to software in general, the CVE program would support it either through CNA-based assignment or through a CNA of last resort.
>
> Am I remembering this correctly?
>
> Dave
>
> -----Original Message-----
> From: Art Manion <>
> Sent: Friday, January 22, 2021 10:52 AM
> To: Kurt Seifried <>
> Cc: CVE Editorial Board Discussion <>
> Subject: Re: CVE IDs for malware
>
>
> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmalvuln.com*2F*23about&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556962138*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=FIIvJZ9LSGIfUsqQtHhnWP7wLqz0zWBUh6iWVJgew7Q*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUl!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1xnVEgrM$
>
> While not a priority, it should IMO be possible to assign CVE IDs to vulnerabilities in any software, including "malware." Remember, the "mal" prefix can be a matter of perspective.
>
> - Art
>
>
> On 2020-08-17 14:54, Art Manion wrote:
> >
> > My recollection, real or imagined, is that it just wasn't a strong use case among CVE consumers. I don't recall if there were active reasons against, like possibly aiding malware developers/users.
> >
> > I think it's good for the CVE Project be separate from any pre-public-disclosure issues (embargo length, coordination issues, malware/goodware, vulnerability equities, etc). When a vulnerability becomes public, it gets a CVE ID, what happens before or after the CVE ID issuance is other peoples' problems.
> >
> > Pretty sure CVE documentation prefers/recommends/suggests coordinated vulnerability disclosure, but does not require it.
> >
> > - Art
> >
> >
> > On 2020-08-17 14:48, Kurt Seifried wrote:
> >> My question would be "Why are we not doing CVEs for malware?" What was the reason for this decision (do we have it documented or is it lost in the ages of time?).
> >>
> >>
> >>
> >>
> >> On Mon, Aug 17, 2020 at 11:58 AM Art Manion < <mailto:>> wrote:
> >>
> >> Two threads based on this story:
> >>
> >> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.zdnet.com*2Farticle*2Ffor-six-months-security-researchers-have-secretly-distributed-an-emotet-vaccine-across-the-world*2F&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556962138*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=9PddX0yPeVZOHgbAuBFzAbXmJFxAlISd7Sy6X*2FqWa7U*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1PkHN0Rc$
> >>
> >> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fzdnet1.cbsistatic.com*2Fhub*2Fi*2F2020*2F08*2F14*2Fe3a34948-ef00-496f-893c-709f8f748899*2Femotet-trolling.png&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556962138*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=tTPzRmQaJE5tW27wa*2F9YQVC5x9*2Fug0I6np5JWU2cFVc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1K12sXT8$
> >>
> >> 1. My opinion is that CVE identifies vulns, period. CVE should be agnostic about the type or use of the software. E.g., one person's lawful intercept software is someone else's malware, and the CVE Project should not be delving into the relative attacker/defender perspective. I don't consider this a high priority work item for the Project.
> >>
> >> 2. I believe the assignment rules have changed, as part of the recent CNA rules update. The screen shot in the ZDNet story mentions INC4 which I believe is deprecated?
> >>
> >> Current rules do not mention INC4 or malware:
> >>
> >> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fcve.mitre.org*2Fcve*2Fcna*2Frules.html*23section_7_assignment_rules&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=5WwZU*2FdM1FNq2MxKqXrIGU0krHtsAGtsXDVubWc6T*2BY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1tzfl1ck$
> >> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fcve.mitre.org*2Fcve*2Fcna*2FCNA_Rules_v3.0.pdf&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Oltw2ndGBzF6z9DsZDhXAyJlK4v8QfQRku9Kj1L*2FaHw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT16NmIskU$
> >>
> >> Deprecated rules, but still published, do mention INC4 and malware:
> >>
> >> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fcve.mitre.org*2Fcve*2Feditorial_policies*2Fcounting_rules.html&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=IjIruocFwjWhHehtJVRXZfq8Xr5e9gHfmFWyIZyZnwM*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1-1BdQp0$
> >> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fcve.mitre.org*2Fcve*2Fcna*2FCNA_Rules_v1.1.pdf&data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Rg*2F*2FiLOxonJWJUrAD*2BaTnHvoOenUV6iCIa96Z9oVWnA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1VX5SQyc$
> >>
> >> Regards,
> >>
> >> - Art
> >>
> >>
> >>
> >> --
> >> Kurt Seifried
> >> <mailto:>
> >
> ... [show rest of quote]

CVE IDs for malware

Discussion Board

Author: Kurt Seifried-2 (08-17-2020)

Author: Art Manion (08-17-2020)

Author: Landfield (08-17-2020)

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Author: Scott Lawler (08-17-2020)

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Author: Art Manion (08-17-2020)

Author: Landfield (08-17-2020)

Author: 5 posts (08-17-2020)

Author: Landfield (08-17-2020)

Author: Waltermire (08-17-2020)

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Author: Kurt Seifried-2 (08-17-2020)

Author: Landfield (08-17-2020)

Author: Scott Lawler (08-17-2020)

This has not been lost to time as there are people on the list that have been here since the CVE dinosaur days....

Author: Waltermire (08-17-2020)

Author: Beverly Miller (08-24-2020)

Author: Art Manion (01-22-2021)

Author: Waltermire (01-25-2021)

Author: Levendis (01-25-2021)

Author: 3 posts (01-25-2021)