RE: CWE/CAPEC Definitions

[Paul.Wortman]

I also agree with dropping the “in a range of….” piece.  It just further 
muddies the water and adds no value.

   - Paul

From: Schweiger, Andreas Dr. 
Sent: Thursday, July 14, 2022 7:58 AM
To: CWE Research Discussion 
Subject: RE: CWE/CAPEC Definitions


Dear all,

dropping the mentioned part of the sentence is a very good idea.

Apart from that I am fine with all three definitions.

Best wishes
Andreas

Dr. rer. nat. Andreas Schweiger, Dipl.-Inf. (Univ.)
System Architect
TOR Embedded RTS Development - TEYXI
Airbus Defence and Space

T   +49 8459 81-67087
M  +49 172 7159582
F   +49 8459 81-78112
E   andreas.schwei...@airbus.com

Airbus Defence and Space GmbH
Rechliner Straße
85077 Manching
Germany

www.airbusdefenceandspace.com

Airbus Defence and Space GmbH

Chairman of the Supervisory Board: Dominik Asam
Managing Directors: Dr. Michael Schoellhorn (Chairman), Dr. Lars Immisch
Registered Office: Ottobrunn
District Court of Munich HRB 107 648
UST. Ident. Nr./VAT reg. no. DE167015661




THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

From: James Pangburn [mailto:jpangb...@cadence.com]
Sent: Wednesday, July 13, 2022 10:49 PM
To: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>; Kurt 
Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: RE: CWE/CAPEC Definitions

I also vote to drop “in a range of …”

Best regards,
Jim Pangburn
Director, IPG Operations

From: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>
Sent: Wednesday, July 13, 2022 1:21 PM
To: Kurt Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: CWE/CAPEC Definitions

EXTERNAL MAIL
Or for that matter non-vendors. Software composition, as an example, Open 
Source, etc.



Best Regards,
Joe Baum
Director, Threat Management Group





On Wed, Jul 13, 2022 at 3:18 PM Kurt Seifried 
mailto:k...@seifried.org>> wrote:
Also, it excludes services. So yeah, I vote drop the " in a range of products 
made by different vendors"

On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz 
mailto:sjoeja...@gmail.com>> wrote:
I still recommend deleting at the end of the definition of weakness "... in a 
range of products made by different vendors.

It adds no value, and actually unintentionally limits applicability by implying 
weaknesses only apply to products made by vendors.

Regards,

Joe

On Wed, Jul 13, 2022, 12:08 Alec J Summers 
mailto:asumm...@mitre.org>> wrote:
Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

Vulnerability

A flaw in a software, firmware, hardware, or service component resulting from a 
weakness that can be exploited, causing a negative impact to the 
confidentiality, integrity, or availability of an impacted component or 
components (from CVE®)

Weakness

A type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could contribute to the introduction of vulnerabilities in a 
range of products made by different vendors

Attack Pattern

The common approach and attributes related to the exploitation of a weakness, 
usually in cyber-enabled capabilities


Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

Cheers,
Alec

--
Alec J. Summers
Center for Securing the Homeland (CSH)
Cyber Security Engineer, Principal
Group Lead, Cybersecurity Operations and Integration

MITRE - Solving Problems for a Safer World™




--
Kurt Seifried (He/Him)
k...@seifried.org


For more information on how and why we collect your personal information, 
please visit our Privacy 

RE: Cross-configuration attacks

[Paul.Wortman]

I would seem, in my opinion and take on this matter, that it really boils down 
to human assumptions on functionality and ability.  This could be incorporated 
in CWE-1053 (Missing Documentation for Design) since the fault seems to come 
from an assumption of behavior (e.g. challenge/response).

Now this could be too much of a simplification of the problem, but it would 
seem the question is more about what is at the heart of this problem (i.e. the 
specific weakness being identified) than if the CWE contains appropriate 
coverage.  Since the purpose of the weaknesses are the general context of the 
potential issue and not the specifics of how they are exactly instantiated in 
the real world (more of a CVE entry) then it appears that there might be a few 
CWEs that could represent the issue.  It all just depends where we would like 
to draw the line in the case of this publication.

   - Paul

From: John Thomas 
Sent: Friday, September 24, 2021 8:22 AM
To: Kurt Seifried ; noloa...@gmail.com
Cc: cwe-research-l...@lists.mitre.org
Subject: RE: Cross-configuration attacks

I think the issue here is the ambiguity in the behavior. If App A knows App B’s 
behavior fully and with no ambiguity and App B knows how App A will respond 
fully and with no ambiguity, then it’s unlikely to be a problem.

The issue is that with the ambiguity, App A cannot fully know/anticipate App 
B’s behavior and/or vice versa. These ambiguities might be harmless within App 
A and within App B, but when they are exchanging information it becomes 
harmful. Indeed, this sort of vulnerability is more dangerous when happening 
between independent components than if it was just an internal issue (although 
this could also cause problems with internal communication when multiple 
engineers have different interpretations and later maintainers might not know 
the implicit choices), since it is highly likely that the designers of 
independent components will have different implicit assumptions. This line from 
the original paper I think supports my interpretation:
“The disagreements on the interpretation of the OpenPGP standard may raise 
doubts on the interoperability between the libraries… While in a basic scenario 
these three libraries can, to the best of our knowledge, in fact interoperate 
securely, we shall now see that some choices made by Crypto++ and gcrypt prove 
to be fatal in a broader context.” (pg. 5)

So at least part of the issue here is a failure of requirements/documentation, 
as much as it is a matter of handling potentially dangerous input (although 
that is also relevant for defense-in-depth).

Is there a CWE for ambiguity in security protocols between multiple parties?

With regards,
John Thomas

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Thursday, September 23, 2021 11:20 PM
To: noloa...@gmail.com
Cc: cwe-research-l...@lists.mitre.org
Subject: Re: Cross-configuration attacks

I assume by CVE you meant CWE, and no there isn't a CWE for "intersection" or 
"mismatch" attacks. I don't like the term cross-configuration unless it's 
actually applied to issues that are created by configuration issues, my concern 
would be technically any intersection vulnerability can be classed as a config 
issue because you could disable most things somehow/somwhere.

Perhaps we need CWE to not just cover weaknesses but normal behaviours so we 
can better describe "normal behaviour A + normal behavior B = weakness 
[described if not specific term exists).

Do we have a list of CVE "intersection" vulns to look at as a data set to see 
what is causing these? E.g. configs? badly written specifications that result 
in different interpretations? One good keyword is "conjunction" but also a lot 
of false positives:

https://nvd.nist.gov/vuln/search/results?form_type=Basic_type=overview=conjunction_type=all=false



On Thu, Sep 23, 2021 at 8:16 PM Jeffrey Walton 
mailto:noloa...@gmail.com>> wrote:
Hi Everyone,

This made my radar recently: 
https://eprint.iacr.org/2021/923.pdf.
 The
interesting thing about the attack is, App A is considered secure in
isolation, and App B is considered secure in isolation, but when
interacting App A and B produce an insecure result.

We've seen bad interactions among components within the same app
before, like incorrectly combining authentication and encryption. But
in this case it is not the same app. Rather, the vulnerability is a
product of two distinct apps using slightly different implementation
details sharing data.

I'm wondering if there's a CVE to cover the