New CWE Weakness Class: Request for Comment

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

New CWE Weakness Class: Request for Comment

asummers
Administrator

Dear CWE Research Community,

 

Good morning – I hope this message reaches you all in good health and spirits!

 

As we work towards the next minor release of CWE content, one of the areas we intend to establish and carefully work to improve over time is defining the underlying weaknesses that manifest in a class of physical security vulnerabilities. We have just finished our first step - drafting a placeholder CWE in this domain for public comment.

 

Please let us know what you think. Are we on the right path?

 

Cheers,

Alec

 

 

Here are the details:

 

CWE-xxxx: Improper Physical Protection Mechanism

Abstraction: Class Level Weakness

 

Description

The product does not protect or incorrectly protects against an unauthorized actor’s ability to physically access restricted regions of the product.

 

Extended Description

Sections of a product intended as restricted may be rendered physically accessible through the inadvertent or intended efforts of a user to compromise the product's physical security. Product design should take into consideration the physical protection portions of the product intended as user inaccessible. Additionally, testing should occur to ensure the manufacturing process results in the intended physical protection mechanism for the product to be deployed.

 

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature             Type     ID        Name

ChildOf             Pillar     693       Protection Mechanism Failure

 

Modes of Introduction                 

Architecture and Design: The product design does not adequately prevent physical access to regions unintended for accessibility.

Testing

Manufacturing: The manufacturing of the product improperly prevents physical access to regions unintended for accessibility.

 

Common Consequences

Confidentiality, Integrity, Access Control

Technical Impact: Varies by Context, Confidentiality, Integrity, and Access Control of product internals may result in a variety of negative outcomes and lead to numerous further compromise to system security.

 

Related Attack Patterns

CAPEC-390      Bypassing Physical Security

 

 

-- 

Alec J. Summers

Cyber Solutions Division

Group Leader, Software Assurance

Cyber Security Engineer, Lead

O: (781) 271-6970

C: (781) 496-8426

––––––––––––––––––––––––––––––––––––

MITRE - Solving Problems for a Safer World

 

Reply | Threaded
Open this post in threaded view
|

[EXT] Re: New CWE Weakness Class: Request for Comment

Kurt Seifried
Can I suggest we make some distinction between types of failures and claimed security, e.g. tamper evident vs tamper proof, aka recycle FIPS?

Like I expect an attacker to be able to open a computer case that has open case detection, but they shouldn't be able to open it in a way that bypasses the detection. 

On Mon, Jun 1, 2020 at 5:46 AM Alec J Summers <[hidden email]> wrote:

Dear CWE Research Community,

 

Good morning – I hope this message reaches you all in good health and spirits!

 

As we work towards the next minor release of CWE content, one of the areas we intend to establish and carefully work to improve over time is defining the underlying weaknesses that manifest in a class of physical security vulnerabilities. We have just finished our first step - drafting a placeholder CWE in this domain for public comment.

 

Please let us know what you think. Are we on the right path?

 

Cheers,

Alec

 

 

Here are the details:

 

CWE-xxxx: Improper Physical Protection Mechanism

Abstraction: Class Level Weakness

 

Description

The product does not protect or incorrectly protects against an unauthorized actor’s ability to physically access restricted regions of the product.

 

Extended Description

Sections of a product intended as restricted may be rendered physically accessible through the inadvertent or intended efforts of a user to compromise the product's physical security. Product design should take into consideration the physical protection portions of the product intended as user inaccessible. Additionally, testing should occur to ensure the manufacturing process results in the intended physical protection mechanism for the product to be deployed.

 

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature             Type     ID        Name

ChildOf             Pillar     693       Protection Mechanism Failure

 

Modes of Introduction                 

Architecture and Design: The product design does not adequately prevent physical access to regions unintended for accessibility.

Testing

Manufacturing: The manufacturing of the product improperly prevents physical access to regions unintended for accessibility.

 

Common Consequences

Confidentiality, Integrity, Access Control

Technical Impact: Varies by Context, Confidentiality, Integrity, and Access Control of product internals may result in a variety of negative outcomes and lead to numerous further compromise to system security.

 

Related Attack Patterns

CAPEC-390      Bypassing Physical Security

 

 

-- 

Alec J. Summers

Cyber Solutions Division

Group Leader, Software Assurance

Cyber Security Engineer, Lead

O: (781) 271-6970

C: (781) 496-8426

––––––––––––––––––––––––––––––––––––

MITRE - Solving Problems for a Safer World

 



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

Re: [EXT] Re: New CWE Weakness Class: Request for Comment

Luke W Malinowski

Hi,

 

I’m not sure if threat models are considered in CWE, but some things that would qualify as “Improper Physical Protection Mechanism” are only vulnerable to somewhat sophisticated threats. Things like decapping are not particularly easy but they do require a lot more skill to exploit than most software weaknesses. Namely, software weaknesses often lead to vulnerabilities that can be exploited by anyone who has an exploitation script, whereas decapping and exploiting whatever pins/balls end up being exposed, or trying to anything on exposed circuitry, feels like a different class of physical protection weaknesses.   

 

My overall point is that I second Kurt’s position, because sufficiently advanced attackers can do a lot against hardware and it’s important to point out failures in claimed security as different from plain security flaws.

 

It could also be argued that my point is covered by common consequences with the Likelihood tag.

 

Best,

Luke

 

From: Kurt Seifried <[hidden email]>
Date: Monday, June 1, 2020 at 11:57 AM
To: Alec J Summers <[hidden email]>
Cc: CWE Research Discussion <[hidden email]>
Subject: [EXT] Re: New CWE Weakness Class: Request for Comment

 

Can I suggest we make some distinction between types of failures and claimed security, e.g. tamper evident vs tamper proof, aka recycle FIPS?

 

Like I expect an attacker to be able to open a computer case that has open case detection, but they shouldn't be able to open it in a way that bypasses the detection. 

 

On Mon, Jun 1, 2020 at 5:46 AM Alec J Summers <[hidden email]> wrote:

Dear CWE Research Community,

 

Good morning – I hope this message reaches you all in good health and spirits!

 

As we work towards the next minor release of CWE content, one of the areas we intend to establish and carefully work to improve over time is defining the underlying weaknesses that manifest in a class of physical security vulnerabilities. We have just finished our first step - drafting a placeholder CWE in this domain for public comment.

 

Please let us know what you think. Are we on the right path?

 

Cheers,

Alec

 

 

Here are the details:

 

CWE-xxxx: Improper Physical Protection Mechanism

Abstraction: Class Level Weakness

 

Description

The product does not protect or incorrectly protects against an unauthorized actor’s ability to physically access restricted regions of the product.

 

Extended Description

Sections of a product intended as restricted may be rendered physically accessible through the inadvertent or intended efforts of a user to compromise the product's physical security. Product design should take into consideration the physical protection portions of the product intended as user inaccessible. Additionally, testing should occur to ensure the manufacturing process results in the intended physical protection mechanism for the product to be deployed.

 

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature             Type     ID        Name

ChildOf             Pillar     693       Protection Mechanism Failure

 

Modes of Introduction                 

Architecture and Design: The product design does not adequately prevent physical access to regions unintended for accessibility.

Testing

Manufacturing: The manufacturing of the product improperly prevents physical access to regions unintended for accessibility.

 

Common Consequences

Confidentiality, Integrity, Access Control

Technical Impact: Varies by Context, Confidentiality, Integrity, and Access Control of product internals may result in a variety of negative outcomes and lead to numerous further compromise to system security.

 

Related Attack Patterns

CAPEC-390      Bypassing Physical Security

 

 

-- 

Alec J. Summers

Cyber Solutions Division

Group Leader, Software Assurance

Cyber Security Engineer, Lead

O: (781) 271-6970

C: (781) 496-8426

––––––––––––––––––––––––––––––––––––

MITRE - Solving Problems for a Safer World

 


 

--

Kurt Seifried
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [EXT] Re: New CWE Weakness Class: Request for Comment

Christey, Steven M.

Sometimes in CWE, we have used “Insufficient” (https://cwe.mitre.org/documents/glossary/#Insufficient) which is applicable “when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance.”  That distinction may be useful when it comes to physical attacks.  Consider in cryptography, for example, where an algorithm might not have any flaws but was created years ago with smaller key lengths and is now computationally easy to defeat with brute force.

 

- Steve

 

 

From: Luke W Malinowski <[hidden email]>
Sent: Tuesday, June 2, 2020 1:27 PM
To: Seifried, Kurt <[hidden email]>; Alec J Summers <[hidden email]>
Cc: CWE Research Discussion <[hidden email]>
Subject: Re: [EXT] Re: New CWE Weakness Class: Request for Comment

 

Hi,

 

I’m not sure if threat models are considered in CWE, but some things that would qualify as “Improper Physical Protection Mechanism” are only vulnerable to somewhat sophisticated threats. Things like decapping are not particularly easy but they do require a lot more skill to exploit than most software weaknesses. Namely, software weaknesses often lead to vulnerabilities that can be exploited by anyone who has an exploitation script, whereas decapping and exploiting whatever pins/balls end up being exposed, or trying to anything on exposed circuitry, feels like a different class of physical protection weaknesses.   

 

My overall point is that I second Kurt’s position, because sufficiently advanced attackers can do a lot against hardware and it’s important to point out failures in claimed security as different from plain security flaws.

 

It could also be argued that my point is covered by common consequences with the Likelihood tag.

 

Best,

Luke

 

From: Kurt Seifried <[hidden email]>
Date: Monday, June 1, 2020 at 11:57 AM
To: Alec J Summers <[hidden email]>
Cc: CWE Research Discussion <[hidden email]>
Subject: [EXT] Re: New CWE Weakness Class: Request for Comment

 

Can I suggest we make some distinction between types of failures and claimed security, e.g. tamper evident vs tamper proof, aka recycle FIPS?

 

Like I expect an attacker to be able to open a computer case that has open case detection, but they shouldn't be able to open it in a way that bypasses the detection. 

 

On Mon, Jun 1, 2020 at 5:46 AM Alec J Summers <[hidden email]> wrote:

Dear CWE Research Community,

 

Good morning – I hope this message reaches you all in good health and spirits!

 

As we work towards the next minor release of CWE content, one of the areas we intend to establish and carefully work to improve over time is defining the underlying weaknesses that manifest in a class of physical security vulnerabilities. We have just finished our first step - drafting a placeholder CWE in this domain for public comment.

 

Please let us know what you think. Are we on the right path?

 

Cheers,

Alec

 

 

Here are the details:

 

CWE-xxxx: Improper Physical Protection Mechanism

Abstraction: Class Level Weakness

 

Description

The product does not protect or incorrectly protects against an unauthorized actor’s ability to physically access restricted regions of the product.

 

Extended Description

Sections of a product intended as restricted may be rendered physically accessible through the inadvertent or intended efforts of a user to compromise the product's physical security. Product design should take into consideration the physical protection portions of the product intended as user inaccessible. Additionally, testing should occur to ensure the manufacturing process results in the intended physical protection mechanism for the product to be deployed.

 

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature             Type     ID        Name

ChildOf             Pillar     693       Protection Mechanism Failure

 

Modes of Introduction                 

Architecture and Design: The product design does not adequately prevent physical access to regions unintended for accessibility.

Testing

Manufacturing: The manufacturing of the product improperly prevents physical access to regions unintended for accessibility.

 

Common Consequences

Confidentiality, Integrity, Access Control

Technical Impact: Varies by Context, Confidentiality, Integrity, and Access Control of product internals may result in a variety of negative outcomes and lead to numerous further compromise to system security.

 

Related Attack Patterns

CAPEC-390      Bypassing Physical Security

 

 

-- 

Alec J. Summers

Cyber Solutions Division

Group Leader, Software Assurance

Cyber Security Engineer, Lead

O: (781) 271-6970

C: (781) 496-8426

––––––––––––––––––––––––––––––––––––

MITRE - Solving Problems for a Safer World

 


 

--

Kurt Seifried
[hidden email]