RE: [EXT] RE: Glossary

[Fung, Jason M]

I agree with the proposed approach.  People just need to keep in mind that even 
definitions from Webster Dictionary (or substitute your favorite) are not liked 
by everyone. 

From: Alec J Summers 
Sent: Monday, July 11, 2022 11:32 AM
To: Fung, Jason M ; Hoole, Alexander 
; jw...@redhat.com; Seifried, Kurt 

Cc: CWE CAPEC Board 
Subject: Re: [EXT] RE: Glossary

Good afternoon!

With the release of the Top25 and CWE v4.8, I wanted to pick this thread up 
from where we got it a month or so ago. As a refresher, the User Experience 
Working Group (UEWG) agreed on these definitions as updates to what are 
currently in the CWE and CAPEC glossaries for these terms:

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
Weakness
A type of mistake made during the implementation, design, or other phases of 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 known 
weakness type, usually in cyber-enabled capabilities

One thing is that this “definitions harmonization” effort started as an effort 
to align definitions across the CWE and CAPEC sites which don’t agree on 
“weakness” and “attack pattern” definitions… surprising, no?

CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and I am hesitant to open that up for further edit at 
this time.

For that reason, I propose CWE and CAPEC adopt the current CVE definition for 
‘vulnerability’, and work to harmonize the ‘weakness’ and ‘attack pattern’ 
definitions on the sites.


  1.  I believe that Jeremy’s definition for weakness focuses too much on the 
absence of a safeguard/control versus a mistake/error. This has come up in 
previous scoping conversations for CWE, where its not always the case that the 
‘absence of a mitigation’ warrants a new weakness type
  2.  I appreciate Alex’s set-theory type definition scheme and I think the 
definitions mostly. For weakness, however, while the UEWG agrees on the ‘XXX 
that could become a vulnerability’, I think the added detail in the table above 
is helpful. The connection between attack patterns and weakness types is 
present in both our definitions as well.

I think we could certainly debate these definitions till the proverbial cows 
come home. I propose using the CWE- and CAPEC-research email listservs for 
further community comment. I’d like to establish a timeline (say Friday, July 
29?) for accepting feedback, after which we can formally the terms in the CWE 
and CAPEC glossaries.

Are there any objections to this course of action? If not, I will send out 
notes to the listservs by midweek.

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™



From: Fung, Jason M mailto:jason.m.f...@intel.com>>
Date: Tuesday, May 31, 2022 at 1:33 PM
To: Hoole, Alexander 
mailto:alexander.ho...@microfocus.com>>, 
jw...@redhat.com<mailto:jw...@redhat.com> 
mailto:jw...@redhat.com>>, Seifried, Kurt 
mailto:k...@seifried.org>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>, CWE CAPEC 
Board mailto:cwe-capec-board-list@mitre.org>>
Subject: RE: [EXT] RE: Glossary
Love the definitions!

The only part to nitpick is this phrase “vulnerability is a property of …”  I 
am not sure if vulnerability is commonly perceived as a “property”.  E.g., the 
following sentence does not read as smoothly if vulnerability is replaced with 
property

“In December of 2021, a new vulnerability (property) has been identified within 
…”

I associate vulnerability as an exploitable bug that takes advantage of 1 or 
more weaknesses.

- Jason

From: Alexander Hoole 
mailto:alexander.ho...@microfocus.com>>
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West mailto:jw...@redhat.com>>; Kurt Seifried 
mailto:k...@seifried.org>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>; CWE CAPEC 
Board mailto:cwe-capec-board-list@mitre.org>>
Subject: [EXT] RE: Glossary

Good afternoon/evening Everyone,

Please consider the following points:

  1.  I agree with Jason O. that the terms are a stepping stone to 
understanding how these concepts play out in the real world.  However, a 
slightly different perspective is the following (without defining all of the 
base terms):
 *   A bug is an instance of a flaw/fault/error/defect in the design, 
development/implementation, or operation of a system.
 *   A weaknesses is a bug that could (i.e., may, or may not) lead to a 
vulnerability. Weakness typ

RE: [EXT] RE: Glossary

[Fung, Jason M]

Love the definitions!

The only part to nitpick is this phrase “vulnerability is a property of …”  I 
am not sure if vulnerability is commonly perceived as a “property”.  E.g., the 
following sentence does not read as smoothly if vulnerability is replaced with 
property

“In December of 2021, a new vulnerability (property) has been identified within 
…”

I associate vulnerability as an exploitable bug that takes advantage of 1 or 
more weaknesses.

- Jason

From: Alexander Hoole 
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West ; Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

Subject: [EXT] RE: Glossary

Good afternoon/evening Everyone,

Please consider the following points:

  1.  I agree with Jason O. that the terms are a stepping stone to 
understanding how these concepts play out in the real world.  However, a 
slightly different perspective is the following (without defining all of the 
base terms):
 *   A bug is an instance of a flaw/fault/error/defect in the design, 
development/implementation, or operation of a system.
 *   A weaknesses is a bug that could (i.e., may, or may not) lead to a 
vulnerability. Weakness types define logical groupings of bugs which share 
similar properties (e.g., Buffer Overflow).
 *   A vulnerability is a property of system requirements, design, 
implementation, or operation that can be accidentally or intentionally 
exploited (resulting in a security failure). A vulnerability is made possible 
due to the presence of one or more underlying weaknesses.
 *   An exploit successfully results in a security failure through one or 
more vulnerabilities which does exploit underlying weaknesses.
 *   An attack is an attempt to exploit one or more vulnerabilities that 
could lead to an exploit. Attack patterns define logical groupings of attacks 
which share similar properties and approaches related to underlying weakness 
types.

Note: the distinction between can and could is a comparison of probability.  
Can is likely to occur.  Could is less likely to occur.

  1.  Regarding the Red Hat definition, if we want to be consistent with other 
standards and best practices, we should probably use the term “control” rather 
than “safeguard” (e.g., NIST SP 800-53 Rev. 5).

To test the observations, we should be able to apply the terms to descript 
actual occurrences in the context we are trying to represent.  For example, 
consider the following:

“In December of 2021, a new vulnerability has been identified within Log4J 
under the common name Log4Shell 
(CVE-2021-44228). This 
vulnerability affects version 2.0-beta9 through 2.15.0 (excluding security 
releases 2.12.2, 2.12.3, and 2.3.1). Specifically, CVE-2021-44228 is caused by 
an underlying JNDI Injection and LDAP Entry Poisoning weaknesses which exists 
in the affected versions. To date, multiple exploits have been recorded across 
the industry where attacks targeting CVE-2021-44228 have been observed (e.g., 
VMWare,
 …).

Thoughts?

Best,
-A

From: Jeremy West 
Sent: Tuesday, May 24, 2022 2:03 PM
To: Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

Subject: Re: Glossary

Correct Kurt.  Process is defined here as an executing process on the stack.

On Tue, May 24, 2022 at 5:01 PM Kurt Seifried 
mailto:k...@seifried.org>> wrote:
"process" means executing process, or like a business process, e.g. password 
reset policy?

On Tue, May 24, 2022 at 2:15 PM Jeremy West 
mailto:jw...@redhat.com>> wrote:
Red Hat adopted the following definition of a weakness a year or so ago. "A 
weakness is specifically the absence of a safeguard in an asset or process that 
provides a higher potential or frequency of a threat occurring, but does not 
meet the exploitability criteria for a vulnerability."  We've also defined 
vulnerability much more broadly to include weaknesses as a subset "A weakness 
or absence of a safeguard in an asset that provides a higher potential or 
frequency of a threat occurring."  We were running into differing opinions when 
we looked at each as separate and unique.  The other factor we've called out 
internally is hardening.  The key difference between a weakness and hardening 
for us is that a weakness is a direct factor in the potential and frequency vs 
hardening which are safeguards which prevent.

On Tue, May 24, 2022 at 12:49 PM Alec J Summers 
mailto:asumm...@mitre.org>> wrote:
Dear CWE/CAPEC Board Members,

Good afternoon! I hope the week is going well for you all.

During a recent CWE/CAPEC User Experience Working Group session, the topic of 
definitions came up – more specifically, the difficulty in agreeing on good 
ones and making sure they are understood by downstream users. It also reminded 
me of Pietro’s comment during our February meeting, I believe, on the 
importance of harmonious definitions for similar terms 

RE: Proposed action: Establishing CWE/CAPEC Crypto Working Group

[Fung, Jason M]

I have the same question on my mind and would like a bit more clarity on the 
goal "how to represent and organize certain concepts in ways that are 
understandable to developers while being consistent with current perspectives 
and principles within the cryptography community".

Crypto best practices vary across products with different shelf lives (e.g., 
cell phones vs. critical infrastructure) and security objectives (e.g., 
physical attacks, side channels).  If this is part of the scope of the WG, it 
needs to recruit domain experts representing a diverse set of industries.  But 
I would start with asking why we are in the business of providing crypto 
guidance rather than pointing audience to available resources.

- Jason

From: Chris Eng 
Sent: Wednesday, September 8, 2021 11:41 AM
To: Alec J Summers ; CWE CAPEC Board 

Subject: RE: Proposed action: Establishing CWE/CAPEC Crypto Working Group

Is it the goal of CWE to provide prescriptive guidance on these things?  If so, 
then you might need a working group to keep up with developments in the space, 
since NIST updates infrequently and usually lags behind industry best practices.

Or is it enough just to have categories for insecure algorithm, insecure 
hashing, predictable PRNG, etc. without getting into the weeds?  If our aim is 
simply to categorize weaknesses, then keeping up with implementation details 
might be out of scope.

I am not opposed to it but would like to better understand what problem you are 
trying to solve here.



From: Alec J Summers mailto:asumm...@mitre.org>>
Sent: Wednesday, September 8, 2021 11:11 AM
To: CWE CAPEC Board 
mailto:cwe-capec-board-list@mitre.org>>
Subject: [EXTERNAL] Proposed action: Establishing CWE/CAPEC Crypto Working Group


This email originated from outside of Veracode.


Dear Board Members,

Good morning! I hope you all had an excellent holiday weekend.

I wanted to update you all on a plan of action around establishing a 
cryptography working group.

Unlike many other topics covered by CWE, cryptography requires highly 
specialized knowledge to perform correctly. Since CWE's early days, that 
knowledge has evolved, but CWE entries have not kept up with the pace of change.

The CWE crypto team is nearing a point in which it must make decisions about 
how to represent and organize certain concepts in ways that are understandable 
to developers while being consistent with current perspectives and principles 
within the cryptography community.

Accordingly, a CWE working group could provide focused discussion to give 
confidence that changes will be beneficial to CWE users.

A cryptography working group would be very helpful to the modernization of CWE 
with respect to cryptography, key management, hashing, 
randomness/predictability, and other related concepts. The group could be drawn 
from CWE crypto team members, interested parties from the CWE research list, 
people who have provided feedback on earlier questions from the crypto team, 
and focused outreach to knowledgeable individuals from academia, NIST, and 
security consultants.

The working group might start off informally with e-mail discussion on broader 
modernization strategies for CWE with respect to crypto, then diving into 
individual topics needing resolution and discussion. A monthly meeting might be 
appropriate for richer discussion. It is not clear how long this working group 
would be necessary, but regular discussions might be necessary until at least 
April 2021. Its benefits would pay off immediately, possibly influencing 
changes in CWE 4.6, scheduled for release in late October.

Please let me know if you have any thoughts or objections to this plan of 
action.

Cheers,
Alec

p.s. If you haven't had a chance to provide feedback to the DRAFT CWE/CAPEC 
Board Charter, please do so by 9/13.

--
Alec J. Summers
Cyber Solutions Innovation Center
Group Leader, Software Assurance Research & Practice
Cyber Security Engineer, Lead
O: (781) 271-6970
C: (781) 496-8426

MITRE - Solving Problems for a Safer World

RE: Launched! CWE/CAPEC UXWG

[Fung, Jason M]

Hi Alec,

Thanks for the exciting update.  The UXWG meeting coincides with a recurring 
meeting of mine and so I cannot participate.  Can you point me to the site 
where I can check out the meeting minutes?

- Jason

From: Alec J Summers 
Sent: Thursday, July 22, 2021 7:33 AM
To: CWE CAPEC Board 
Subject: Launched! CWE/CAPEC UXWG

Dear CWE/CAPEC Board Members,

Good morning - I hope you are all well!

I wanted to send a quick note to let you know that we kicked off the CWE/CAPEC 
User Experience Working Group last Wednesday. We had roughly two dozen people 
in attendance from a variety of organizations. After laying the groundwork for 
'why we were there' - the setting up of the group as an action taken in 
response to a variety of negative community feedback about CWE/CAPEC usability 
over the last few years - we had an engaging conversation about the different 
types of CWE/CAPEC users. In short, attendees volunteered to talk through their 
respective roles, the work they do, and how CWE/CAPEC enters into it.

Our first order of business with the UXWG is to formally identify and define 
the CWE/CAPEC User 'Personas' - or the various types of users of our 
information corpuses. Once the Personas are enumerated, we intend to dive into 
the details of how those Personas use our information and how their needs could 
be better served. At its core, this is all in an effort to modernize our 
program through community engagement.

The CWE/CAPEC UXWG meets on a bi-weekly basis. It reports to you, the CWE/CAPEC 
Board, and so we intend to establish a mechanism and cadence for that going 
forward.

Cheers,
Alec

--
Alec J. Summers
Cyber Solutions Innovation Center
Group Leader, Software Assurance Research & Practice
Cyber Security Engineer, Lead
O: (781) 271-6970
C: (781) 496-8426

MITRE - Solving Problems for a Safer World