:59 PM
To: Jason Oberg
Cc: Fung, Jason , Alec J Summers ,
Hoole, Alexander , jw...@redhat.com
, Seifried, Kurt , CWE CAPEC Board
Subject: Re: [EXT] RE: Glossary
I'm OK with not further tweaking the definition of 'vulnerability'; yet while
providing updated definitions for 'weakness
te)
>> are not liked by everyone.
>>
>>
>>
>> *From:* Alec J Summers
>> *Sent:* Monday, July 11, 2022 11:32 AM
>> *To:* Fung, Jason M ; Hoole, Alexander <
>> alexander.ho...@microfocus.com>; jw...@redhat.com; Seifried, Kurt <
>> k...@s
gt;
> *From:* Alec J Summers
> *Sent:* Monday, July 11, 2022 11:32 AM
> *To:* Fung, Jason M ; Hoole, Alexander <
> alexander.ho...@microfocus.com>; jw...@redhat.com; Seifried, Kurt <
> k...@seifried.org>
> *Cc:* CWE CAPEC Board
> *Subject:* Re: [EXT] RE: Glossary
; 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
and Integration
>
> **
>
> *MITRE - Solving Problems for a Safer World™*
>
>
>
>
>
>
>
> *From: *Fung, Jason M
> *Date: *Tuesday, May 31, 2022 at 1:33 PM
> *To: *Hoole, Alexander , jw...@redhat.com
> , Seifried, Kurt
>
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
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
On Tue, May 24, 2022 at 4:32 PM Jason Oberg wrote:
> Jeremy, welcome!
>
> I like the idea of defining a weakness wrt to a protection for an asset.
> The protection could have weaknesses because of mistakes, forgetfulness, or
> any other reason (e.g. environment). An asset-based definition fits
Just a quick correction… see below. Upon reflection, the example should not
attribute an LDAP Entry Poisoning vuln (only JNDI Injection). An attack chain,
which could include an LDAP Entry Poising vector (or more simply a maliciously
controlled LDAP Server), could be part of a remote code
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
Jeremy, welcome!
I like the idea of defining a weakness wrt to a protection for an asset.
The protection could have weaknesses because of mistakes, forgetfulness, or
any other reason (e.g. environment). An asset-based definition fits really
well for hardware and I think for a lot of software, but
Hi Alec and all,
Happy to hear there is an initiative to help align these definitions. I
know it's a very common confusion point for many.
A couple of thoughts/comments from me:
- In the weakness definition the word "mistake" throws me off a bit
because that implies there was awareness of
12 matches
Mail list logo
