CVE IDs for malware

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CVE IDs for malware

Art Manion
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
Reply | Threaded
Open this post in threaded view
|

CVE IDs for malware

Shannon Sabens
Strong agree with 1, yes.

On 8/17/20, 10:59 AM, "Art Manion" <[hidden email]> wrote:

    Two threads based on this story:

    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_for-2Dsix-2Dmonths-2Dsecurity-2Dresearchers-2Dhave-2Dsecretly-2Ddistributed-2Dan-2Demotet-2Dvaccine-2Dacross-2Dthe-2Dworld_&d=DwICaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=klPugXk2dM9ofnCzmtt5xxv6K4_JXIv0Ex34ahjAEic&m=b0dSLFwEDp_0Kv9T5uRIZimzQB4EWvnFNtopanEjg4U&s=F1S5srpiaP4WVJVZNeFPGJ1Klak5qzhzqxfXa7n0OT8&e= 

    https://urldefense.proofpoint.com/v2/url?u=https-3A__zdnet1.cbsistatic.com_hub_i_2020_08_14_e3a34948-2Def00-2D496f-2D893c-2D709f8f748899_emotet-2Dtrolling.png&d=DwICaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=klPugXk2dM9ofnCzmtt5xxv6K4_JXIv0Ex34ahjAEic&m=b0dSLFwEDp_0Kv9T5uRIZimzQB4EWvnFNtopanEjg4U&s=41r0ZfpppG4iFcEhXqvrg1dGGKZnyT6FAPFfvrW6jEQ&e= 

    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.proofpoint.com/v2/url?u=https-3A__cve.mitre.org_cve_cna_rules.html-23section-5F7-5Fassignment-5Frules&d=DwICaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=klPugXk2dM9ofnCzmtt5xxv6K4_JXIv0Ex34ahjAEic&m=b0dSLFwEDp_0Kv9T5uRIZimzQB4EWvnFNtopanEjg4U&s=2hRBsOb2fQorsFC2DRrPl5AdWPWNLSX9bBb0d3DcXRo&e= 
    https://urldefense.proofpoint.com/v2/url?u=https-3A__cve.mitre.org_cve_cna_CNA-5FRules-5Fv3.0.pdf&d=DwICaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=klPugXk2dM9ofnCzmtt5xxv6K4_JXIv0Ex34ahjAEic&m=b0dSLFwEDp_0Kv9T5uRIZimzQB4EWvnFNtopanEjg4U&s=WUDSm5b11BnPnZSizupQFYZlOyeH1T37QoIobUTZ42A&e= 

    Deprecated rules, but still published, do mention INC4 and malware:

    https://urldefense.proofpoint.com/v2/url?u=https-3A__cve.mitre.org_cve_editorial-5Fpolicies_counting-5Frules.html&d=DwICaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=klPugXk2dM9ofnCzmtt5xxv6K4_JXIv0Ex34ahjAEic&m=b0dSLFwEDp_0Kv9T5uRIZimzQB4EWvnFNtopanEjg4U&s=gLjinp5UF5YI7ZdjK_OD9HMMoo6qLjZI5v9xBz9UYhc&e= 
    https://urldefense.proofpoint.com/v2/url?u=https-3A__cve.mitre.org_cve_cna_CNA-5FRules-5Fv1.1.pdf&d=DwICaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=klPugXk2dM9ofnCzmtt5xxv6K4_JXIv0Ex34ahjAEic&m=b0dSLFwEDp_0Kv9T5uRIZimzQB4EWvnFNtopanEjg4U&s=AAusohLewzbXqt_SKAkQBYOjwIxGSFnkMNWV2TaNRCo&e= 

    Regards,

     - Art

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Kurt Seifried-2
In reply to this post by Art Manion
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 <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Art Manion

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 <[hidden email] <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Landfield, Kent
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

[hidden email]

 

 

From: Kurt Seifried <[hidden email]>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: CVE IDs for malware

Scott Lawler

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

[hidden email]

703-509-9330

 

For Cyber Emergencies email: [hidden email]

 

 

From: "Landfield, Kent" <[hidden email]>
Date: Monday, August 17, 2020 at 3:10 PM
To: Kurt Seifried <[hidden email]>, Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

 

 

From: Kurt Seifried <[hidden email]>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: CVE IDs for malware

Art Manion
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
>
> [hidden email]
>
> 703-509-9330
>
>  
>
> For Cyber Emergencies email: [hidden email] <mailto:[hidden email]>
>
>  
>
>  
>
> *From: *"Landfield, Kent" <[hidden email]>
> *Date: *Monday, August 17, 2020 at 3:10 PM
> *To: *Kurt Seifried <[hidden email]>, Art Manion <[hidden email]>
> *Cc: *CVE Editorial Board Discussion <[hidden email]>
> *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
>
> [hidden email] <mailto:[hidden email]>
>
>  
>
>  
>
> *From: *Kurt Seifried <[hidden email]>
> *Date: *Monday, August 17, 2020 at 1:49 PM
> *To: *Art Manion <[hidden email]>
> *Cc: *CVE Editorial Board Discussion <[hidden email]>
> *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 <[hidden email] <mailto:[hidden email]>> 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
> [hidden email] <mailto:[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: CVE IDs for malware

Landfield, Kent
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
[hidden email]
 

On 8/17/20, 2:40 PM, "Art Manion" <[hidden email]> 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
    >
    > [hidden email]
    >
    > 703-509-9330
    >
    >  
    >
    > For Cyber Emergencies email: [hidden email] <mailto:[hidden email]>
    >
    >  
    >
    >  
    >
    > *From: *"Landfield, Kent" <[hidden email]>
    > *Date: *Monday, August 17, 2020 at 3:10 PM
    > *To: *Kurt Seifried <[hidden email]>, Art Manion <[hidden email]>
    > *Cc: *CVE Editorial Board Discussion <[hidden email]>
    > *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
    >
    > [hidden email] <mailto:[hidden email]>
    >
    >  
    >
    >  
    >
    > *From: *Kurt Seifried <[hidden email]>
    > *Date: *Monday, August 17, 2020 at 1:49 PM
    > *To: *Art Manion <[hidden email]>
    > *Cc: *CVE Editorial Board Discussion <[hidden email]>
    > *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 <[hidden email] <mailto:[hidden email]>> 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
    > [hidden email] <mailto:[hidden email]>
    >


Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

tk blast
In reply to this post by Art Manion
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 <[hidden email]> 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


--

Tim "TK" Keanini
mbl 415 328 2722
twtr @tkeanini

Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Landfield, Kent

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

[hidden email]

 

 

From: Tim Keanini <[hidden email]>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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


 

--


Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

 

Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: CVE IDs for malware

Waltermire, David A.
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 <[hidden email]>
Sent: Monday, August 17, 2020 3:16 PM
To: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

703-509-9330

 

For Cyber Emergencies email: [hidden email]

 

 

From: "Landfield, Kent" <[hidden email]>
Date: Monday, August 17, 2020 at 3:10 PM
To: Kurt Seifried <[hidden email]>, Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

 

 

From: Kurt Seifried <[hidden email]>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Kurt Seifried-2
In reply to this post by Landfield, Kent
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 <[hidden email]> wrote:

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

[hidden email]

 

 

From: Tim Keanini <[hidden email]>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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


 

--


Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

 



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Landfield, Kent

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

[hidden email]

 

 

From: Kurt Seifried <[hidden email]>
Date: Monday, August 17, 2020 at 3:27 PM
To: Kent Landfield <[hidden email]>
Cc: Tim Keanini <[hidden email]>, Art Manion <[hidden email]>, CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> wrote:

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

[hidden email]

 

 

From: Tim Keanini <[hidden email]>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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


 

--


Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

 


 

--

Kurt Seifried
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: CVE IDs for malware

Scott Lawler
In reply to this post by Waltermire, David A.

Concur! 

 

 

Thank you,  

Scott

[hidden email]

703-509-9330

 

For Cyber Emergencies email: [hidden email]

 

 

From: "Waltermire, David A. (Fed)" <[hidden email]>
Date: Monday, August 17, 2020 at 4:12 PM
To: S Lawler <[hidden email]>, CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]>
Sent: Monday, August 17, 2020 3:16 PM
To: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

703-509-9330

 

For Cyber Emergencies email: [hidden email]

 

 

From: "Landfield, Kent" <[hidden email]>
Date: Monday, August 17, 2020 at 3:10 PM
To: Kurt Seifried <[hidden email]>, Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

 

 

From: Kurt Seifried <[hidden email]>
Date: Monday, August 17, 2020 at 1:49 PM
To: Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CVE IDs for malware

Waltermire, David A.
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 <[hidden email]>
Sent: Monday, August 17, 2020 4:10 PM
To: tk blast <[hidden email]>; Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

 

 

From: Tim Keanini <[hidden email]>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <
[hidden email]>
Cc: CVE Editorial Board Discussion <
[hidden email]>
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 <[hidden email]> 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


 

--


Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

 

Reply | Threaded
Open this post in threaded view
|

RE: [External] RE: CVE IDs for malware

Beverly Miller

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 Manager
Product Security Office

919-294-5873
[hidden email]

 

Lenovo.com 
Twitter | Instagram | Facebook | Linkedin | YouTube | Privacy 

 

 

From: Waltermire, David A. (Fed) <[hidden email]>
Sent: Monday, August 17, 2020 11:41 PM
To: Landfield, Kent <[hidden email]>; tk blast <[hidden email]>; Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]>
Sent: Monday, August 17, 2020 4:10 PM
To: tk blast <[hidden email]>; Art Manion <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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

[hidden email]

 

 

From: Tim Keanini <[hidden email]>
Date: Monday, August 17, 2020 at 3:02 PM
To: Art Manion <
[hidden email]>
Cc: CVE Editorial Board Discussion <
[hidden email]>
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 <[hidden email]> 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


 

--


Tim "TK" Keanini

mbl 415 328 2722

twtr @tkeanini

 

Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Art Manion
In reply to this post by Art Manion

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 <[hidden email] <mailto:[hidden email]>> 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
>> [hidden email] <mailto:[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

RE: CVE IDs for malware

Waltermire, David A.
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 <[hidden email]>
Sent: Friday, January 22, 2021 10:52 AM
To: Kurt Seifried <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
Subject: Re: CVE IDs for malware


https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmalvuln.com%2F%23about&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=FIIvJZ9LSGIfUsqQtHhnWP7wLqz0zWBUh6iWVJgew7Q%3D&amp;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 <[hidden email] <mailto:[hidden email]>> 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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9PddX0yPeVZOHgbAuBFzAbXmJFxAlISd7Sy6X%2FqWa7U%3D&amp;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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tTPzRmQaJE5tW27wa%2F9YQVC5x9%2Fug0I6np5JWU2cFVc%3D&amp;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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5WwZU%2FdM1FNq2MxKqXrIGU0krHtsAGtsXDVubWc6T%2BY%3D&amp;reserved=0
>>      https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2FCNA_Rules_v3.0.pdf&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Oltw2ndGBzF6z9DsZDhXAyJlK4v8QfQRku9Kj1L%2FaHw%3D&amp;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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IjIruocFwjWhHehtJVRXZfq8Xr5e9gHfmFWyIZyZnwM%3D&amp;reserved=0
>>      https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2FCNA_Rules_v1.1.pdf&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Rg%2F%2FiLOxonJWJUrAD%2BaTnHvoOenUV6iCIa96Z9oVWnA%3D&amp;reserved=0
>>
>>      Regards,
>>
>>       - Art
>>
>>
>>
>> --
>> Kurt Seifried
>> [hidden email] <mailto:[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Levendis, Chris
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


From: Waltermire, David A. (Fed) <[hidden email]>
Sent: Monday, January 25, 2021 1:51:39 PM
To: Manion, Art <[hidden email]>; Seifried, Kurt <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
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 <[hidden email]>
Sent: Friday, January 22, 2021 10:52 AM
To: Kurt Seifried <[hidden email]>
Cc: CVE Editorial Board Discussion <[hidden email]>
Subject: Re: CVE IDs for malware


https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmalvuln.com%2F%23about&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=FIIvJZ9LSGIfUsqQtHhnWP7wLqz0zWBUh6iWVJgew7Q%3D&amp;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 <[hidden email] <[hidden email]>> 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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9PddX0yPeVZOHgbAuBFzAbXmJFxAlISd7Sy6X%2FqWa7U%3D&amp;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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556962138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tTPzRmQaJE5tW27wa%2F9YQVC5x9%2Fug0I6np5JWU2cFVc%3D&amp;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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5WwZU%2FdM1FNq2MxKqXrIGU0krHtsAGtsXDVubWc6T%2BY%3D&amp;reserved=0
>>      https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2FCNA_Rules_v3.0.pdf&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Oltw2ndGBzF6z9DsZDhXAyJlK4v8QfQRku9Kj1L%2FaHw%3D&amp;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&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IjIruocFwjWhHehtJVRXZfq8Xr5e9gHfmFWyIZyZnwM%3D&amp;reserved=0
>>      https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcve%2Fcna%2FCNA_Rules_v1.1.pdf&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C666e475dc9044a4be8ba08d8beedbaa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637469275556972098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Rg%2F%2FiLOxonJWJUrAD%2BaTnHvoOenUV6iCIa96Z9oVWnA%3D&amp;reserved=0
>>
>>      Regards,
>>
>>       - Art
>>
>>
>>
>> --
>> Kurt Seifried
>> [hidden email] <[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

Re: CVE IDs for malware

Pascal Meunier-2
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 <[hidden email]> 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) <[hidden email]>
> Sent: Monday, January 25, 2021 1:51:39 PM
> To: Manion, Art <[hidden email]>; Seifried, Kurt <[hidden email]>
> Cc: CVE Editorial Board Discussion <[hidden email]>
> 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 <[hidden email]>
> Sent: Friday, January 22, 2021 10:52 AM
> To: Kurt Seifried <[hidden email]>
> Cc: CVE Editorial Board Discussion <[hidden email]>
> Subject: Re: CVE IDs for malware
>
>
> https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmalvuln.com*2F*23about&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556962138*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=FIIvJZ9LSGIfUsqQtHhnWP7wLqz0zWBUh6iWVJgew7Q*3D&amp;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 <[hidden email] <mailto:[hidden email]>> 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&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556962138*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=9PddX0yPeVZOHgbAuBFzAbXmJFxAlISd7Sy6X*2FqWa7U*3D&amp;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&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556962138*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=tTPzRmQaJE5tW27wa*2F9YQVC5x9*2Fug0I6np5JWU2cFVc*3D&amp;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&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=5WwZU*2FdM1FNq2MxKqXrIGU0krHtsAGtsXDVubWc6T*2BY*3D&amp;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&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=Oltw2ndGBzF6z9DsZDhXAyJlK4v8QfQRku9Kj1L*2FaHw*3D&amp;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&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=IjIruocFwjWhHehtJVRXZfq8Xr5e9gHfmFWyIZyZnwM*3D&amp;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&amp;data=04*7C01*7Cdavid.waltermire*40nist.gov*7C666e475dc9044a4be8ba08d8beedbaa3*7C2ab5d82fd8fa4797a93e054655c61dec*7C1*7C0*7C637469275556972098*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=Rg*2F*2FiLOxonJWJUrAD*2BaTnHvoOenUV6iCIa96Z9oVWnA*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!Mih3wA!Wn2U433Yjzxedr-Yvtj7dT1KRi-ToINmlqkQw_h-hQR_N9c3Tvo3smT1VX5SQyc$ 
> >>
> >>      Regards,
> >>
> >>       - Art
> >>
> >>
> >>
> >> --
> >> Kurt Seifried
> >> [hidden email] <mailto:[hidden email]>  
> >  
>

12