CWE Configuration Category

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

CWE Configuration Category

Andrew Buttner
Administrator
CWE Community,

We are working through our upcoming version 4.0 release. We have been
deprecating many categories that are under-used or are no longer appropriate
in an attempt to simplify CWE. A unique case is CWE-16 : Configuration.
Configuration is a phase of the SDLC in which many different types of
weaknesses can take place. Weaknesses in the Software Development view are
not organized around phase, not phases. Hence this category has never found
its proper home.

This category has been used many times in the past, but used
inappropriately.  People often map to CWE-16 for any configuration related
issue, when they should be mapping to a specific weaknesses instead. For
version 4.0 we are strongly considering deprecating this entry as this phase
is represented via the Mode of Introduction field, and weaknesses that
pertain this can be discovered through a query on that field.  We are
thinking that the category is no longer needed.

We do not plan on using this category in any of the views in version 4.0,
and all categories are already discouraged for use in mapping exercises.
Our only hesitation stopping us from deprecating this is its extensive prior
use within the community.

Are we ok to deprecate this?  Or do you have strong opinions about why this
needs to stay?

Thoughts?




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

[EXT] Re: CWE Configuration Category

David Maxwell-2
A lot of what I would be inclined to call 'Configuration' issues can actually be lumped 
under CWE-355 User Interface Security Issues. It might be argued that configuration
that's done in files is different, because the validation done at file read is not the same
as interactive validation done in a UI, or because the config file isn't a 'user interface' in
all senses. e.g. enabling features A and B together has a bad consequence...

Otherwise, I can't think of a reason CWE-16 needs to live on.

David Maxwell


On Tue, Jan 28, 2020 at 3:00 PM Buttner, Drew <[hidden email]> wrote:
CWE Community,

We are working through our upcoming version 4.0 release. We have been
deprecating many categories that are under-used or are no longer appropriate
in an attempt to simplify CWE. A unique case is CWE-16 : Configuration.
Configuration is a phase of the SDLC in which many different types of
weaknesses can take place. Weaknesses in the Software Development view are
not organized around phase, not phases. Hence this category has never found
its proper home.

This category has been used many times in the past, but used
inappropriately.  People often map to CWE-16 for any configuration related
issue, when they should be mapping to a specific weaknesses instead. For
version 4.0 we are strongly considering deprecating this entry as this phase
is represented via the Mode of Introduction field, and weaknesses that
pertain this can be discovered through a query on that field.  We are
thinking that the category is no longer needed.

We do not plan on using this category in any of the views in version 4.0,
and all categories are already discouraged for use in mapping exercises.
Our only hesitation stopping us from deprecating this is its extensive prior
use within the community.

Are we ok to deprecate this?  Or do you have strong opinions about why this
needs to stay?

Thoughts?



Reply | Threaded
Open this post in threaded view
|

[EXT] RE: CWE Configuration Category

Wheeler, David A
In reply to this post by Andrew Buttner
From: Buttner, Drew <[hidden email]>
> A unique case is CWE-16 : Configuration.
> Configuration is a phase of the SDLC in which many different types of
> weaknesses can take place. ...

SDLC phases are very organization-specific, there's no wide national or international standard.
Also, I've never heard of "configuration" being claimed to be a "phase in the SDLC",
though perhaps it happens somewhere.

Lifecycle standards like ISO/IEC/IEEE 12207 are organized around processes, not phases.

> ... as this phase is represented via the Mode of Introduction field, and weaknesses that
> pertain this can be discovered through a query on that field.  We are
> thinking that the category is no longer needed.

> Our only hesitation stopping us from deprecating this is its extensive prior
> use within the community.

That is a very good reason to hesitate :-).

Clearly a very large number of vulnerabilities can and *are* introduced
by bad configurations. (E.g., the underlying software is fine, but vendor X has
configured it so that all delivered boxes have user/password as "admin/admin".)

Can you please provide a few specific examples of what this
change would look like?

--- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

RE: [EXT] RE: CWE Configuration Category

Andrew Buttner
Administrator
Thank you for the clarification regarding SDLC.  I think what was meant was
that configuration is a part/step of the overall lifecycle of a product.
Similar to design, implementation, testing, supply chain, etc.  These
concepts are not what CWE has focused on when creating categories.  Rather,
these steps are differentiated by views, or through the Mode of Introduction
fields.  Categories in CWE, specifically for the software development view,
have focused on lower-level concepts that a development team needs to worry
about. Examples of these lower-level categories are Authorization, Logging,
Concurrency, etc.

The updated Software Development view for CWE version 4.0 is a flatter view
then what exists today.  At the top are ~40 categories that hopefully
resonate with architects and coders, with each of the categories having a
flat collection of 5-15 weaknesses under it. (typically at the BASE level)
Note
that the rich set of parent child relationships to CLASS and VARIANTS are
not
going away, but rather they will be the focus of the Research Concepts view
(as they are today).  Our hope is that this simpler Software Development
view, and the similar Hardware Design view will be easier for users to
comprehend and use, while the Research Concepts view will support
academics and CWE power users.

With this structure, the category "Configuration" doesn't seem to fit.  Even
today there are only a limited number of entries under it.  Part of the
reason I think that we are challenged with this is that mis-configurations
mostly lead to / create weaknesses that are covered elsewhere in CWE,
such as permission problems, cleartext transmission, etc.

Thanks
Drew


** Below is a draft of categories for the Software Development view in
version 4.0

API / Function Errors
Audit / Logging Errors
Authentication Errors
Authorization Errors
Bad Coding Practices
Behavioral Problems
Channel and Path Errors
Communication Errors
Complexity Issues
Concurrency Issues
Credentials Management Errors
Data Integrity Issues
Data Processing Errors
Data Representation Errors
Documentation Issues
Encapsulation Issues
Encryption Errors
Error Conditions, Return Values, Status Codes
Expression Issues
Handler Errors
Information Management Errors
Initialization and Cleanup Errors
Input Validation Issues
Lockout Mechanism Errors
Memory Buffer Errors
Numeric Errors
Pathname Traversal and Equivalence Errors
Permission Issues
Pointer Issues
Privilege Issues
Resource Locking Problems
Resource Management Errors
Signal Errors
State Issues
String Errors
Temporary File Issues
Type Errors
User Interface Security Issues
User Session Errors







> -----Original Message-----
> From: Wheeler, David A <[hidden email]>
> Sent: Wednesday, January 29, 2020 10:16 AM
> To: Buttner, Drew <[hidden email]>; CWE Research Discussion <cwe-
> [hidden email]>
> Subject: [EXT] RE: CWE Configuration Category
>
> From: Buttner, Drew <[hidden email]>
> > A unique case is CWE-16 : Configuration.
> > Configuration is a phase of the SDLC in which many different types of
> > weaknesses can take place. ...
>
> SDLC phases are very organization-specific, there's no wide national or
> international standard.
> Also, I've never heard of "configuration" being claimed to be a "phase in
the
> SDLC", though perhaps it happens somewhere.
>
> Lifecycle standards like ISO/IEC/IEEE 12207 are organized around
processes,

> not phases.
>
> > ... as this phase is represented via the Mode of Introduction field,
> > and weaknesses that pertain this can be discovered through a query on
> > that field.  We are thinking that the category is no longer needed.
>
> > Our only hesitation stopping us from deprecating this is its extensive
> > prior use within the community.
>
> That is a very good reason to hesitate :-).
>
> Clearly a very large number of vulnerabilities can and *are* introduced by
> bad configurations. (E.g., the underlying software is fine, but vendor X
has
> configured it so that all delivered boxes have user/password as
> "admin/admin".)
>
> Can you please provide a few specific examples of what this change would
> look like?
>
> --- David A. Wheeler

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

RE: [EXT] RE: CWE Configuration Category

Wheeler, David A
Buttner, Drew <[hidden email]> :
> Thank you for the clarification regarding SDLC.  I think what was meant was
> that configuration is a part/step of the overall lifecycle of a product.
...
> With this [new] structure, the category "Configuration" doesn't seem to fit.
> ... mis-configurations
> mostly lead to / create weaknesses that are covered elsewhere in CWE,
> such as permission problems, cleartext transmission, etc.

Please let me walk through an example of what I *think* you
mean, and then tell me if that's what you meant.

A common configuration failing is a known username/password pair, e.g.,
"root/root" and "admin/admin" are often set when vendors deliver products.
I think that should be a CWE; for argument
let's say it is, as "CWE-XYZ Password known by someone other than user".
Under this regime, I would put CWE-XYZ under "Credentials Management Errors"
(you could argue it's "Authentication Errors" but I think it's really
credentials management error).
In the CWE-XYZ text, you would note that the "Mode of Introduction" is often "configuration".
That does raise a question - is "mode of introduction" a fixed value for each CWE?

Is this what you have in mind?

If so, I think this needs to be discussed somewhere "up front" for people who
are new to (this version of) the CWE. It *will* be surprising that there aren't
CWEs focused on configuration. It might be helpful, in that introduction, to
note several CWEs that are especially important while configuring something.

--- David A. Wheeler

Reply | Threaded
Open this post in threaded view
|

RE: [EXT] RE: CWE Configuration Category

Coles, Matthew
Hello,

I'd like to suggest/propose this specific example (a default credential),
there are 2 potential weaknesses to come from it, one of which might be
considered a configuration related issue. Consider:

Weakness 1: System _has_ a default/well-known username and password
(credentials)
Phase Introduced: Design - vendors set default credentials

Weakness 2: "System owner _uses_" or "system deploys with" default/preset
credentials
Phase Introduced: Configuration (as a part of a deployment action, as a
hardening step - is hardening part of configuration?)

Note that this probably differs from CWE-798 "Use of Hard-Coded
Credentials", since in this case the credentials may not be fixed (i.e. may
be changeable by some user).
Please also note that there is a CAPEC-70 which related to the use of
_default_ credentials, but links to CWE-798 for _hard-coded_ credentials.

In this case, I think there is a good argument for having like
Configuration, but maybe not as a distinct phase. Maybe phases should align
to the phases such as outlined in NIST 800-160 for system development and
deployment (not restricted solely to software) or a similar reference; it is
unclear if the CSF would be appropriate here though given the phases defined
there are more operational in nature (although configuration is an
operational task so maybe).


Matthew Coles
Product Security

BOSE


Classified as Public

-----Original Message-----
From: Wheeler, David A <[hidden email]>
Sent: Wednesday, January 29, 2020 15:27
To: Buttner, Drew <[hidden email]>; CWE Research Discussion
<[hidden email]>
Subject: RE: [EXT] RE: CWE Configuration Category

Buttner, Drew <[hidden email]> :
> Thank you for the clarification regarding SDLC.  I think what was
> meant was that configuration is a part/step of the overall lifecycle of a
product.
...
> With this [new] structure, the category "Configuration" doesn't seem to
fit.
> ... mis-configurations
> mostly lead to / create weaknesses that are covered elsewhere in CWE,
> such as permission problems, cleartext transmission, etc.

Please let me walk through an example of what I *think* you mean, and then
tell me if that's what you meant.

A common configuration failing is a known username/password pair, e.g.,
"root/root" and "admin/admin" are often set when vendors deliver products.
I think that should be a CWE; for argument let's say it is, as "CWE-XYZ
Password known by someone other than user".
Under this regime, I would put CWE-XYZ under "Credentials Management Errors"
(you could argue it's "Authentication Errors" but I think it's really
credentials management error).
In the CWE-XYZ text, you would note that the "Mode of Introduction" is often
"configuration".
That does raise a question - is "mode of introduction" a fixed value for
each CWE?

Is this what you have in mind?

If so, I think this needs to be discussed somewhere "up front" for people
who are new to (this version of) the CWE. It *will* be surprising that there
aren't CWEs focused on configuration. It might be helpful, in that
introduction, to note several CWEs that are especially important while
configuring something.

--- David A. Wheeler

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

RE: [EXT] RE: CWE Configuration Category

Andrew Buttner
Administrator
I like the default password example that David brought up, and the break out
of it by Matthew into two potential issues.

"Weakness 1" which covers the system having an insecure default password is
a weakness in the design or implementation of a product, and I think is
currently covered by "CWE-1188 : Insecure Default Initialization of
Resource". (we should add this example as a demonstrative example to this
CWE, and maybe add a new variant)  I would not consider this a configuration
issue.

"Weakness 2" which covers the owner/admin not changing a default password
would be a configuration issue.  This is not a mistake by the software, but
rather a mistake by the user/human.  Note that this is different than a
potential weakness of "software does not force a user to change the default
password".  (maybe CWE should add that!)

Regarding "Weakness 2", I think the question is if CWE does/should/can cover
mistakes made by users/admins. I argue that this is outside of CWE's current
scope. This is similar to how human mistakes that enable social engineering
attacks are not represented.  Should CWE expand into "human mistakes"
someday?

In the short-term, specifically related to "CWE-16 : Configuration" ... I do
not feel that this category is appropriate for the Software Development
view. However, given its use and the obvious issues that can arise due to
mistakes during configuration, maybe the best course of action is to change
the category to a Class level weakness that covers improper configuration.

As an aside, this aligns with our past maintenance note for this entry.

Does this approach sound reasonable to the community?

Thanks
Drew




> -----Original Message-----
> From: Coles, Matthew <[hidden email]>
> Sent: Wednesday, January 29, 2020 4:44 PM
> To: Buttner, Drew <[hidden email]>; CWE Research Discussion <cwe-
> [hidden email]>
> Subject: RE: [EXT] RE: CWE Configuration Category
>
> Hello,
>
> I'd like to suggest/propose this specific example (a default credential),
> there are 2 potential weaknesses to come from it, one of which might be
> considered a configuration related issue. Consider:
>
> Weakness 1: System _has_ a default/well-known username and password
> (credentials)
> Phase Introduced: Design - vendors set default credentials
>
> Weakness 2: "System owner _uses_" or "system deploys with"
> default/preset
> credentials
> Phase Introduced: Configuration (as a part of a deployment action, as a
> hardening step - is hardening part of configuration?)
>
> Note that this probably differs from CWE-798 "Use of Hard-Coded
> Credentials", since in this case the credentials may not be fixed (i.e.
may
> be changeable by some user).
> Please also note that there is a CAPEC-70 which related to the use of
> _default_ credentials, but links to CWE-798 for _hard-coded_ credentials.
>
> In this case, I think there is a good argument for having like
> Configuration, but maybe not as a distinct phase. Maybe phases should
align
> to the phases such as outlined in NIST 800-160 for system development and
> deployment (not restricted solely to software) or a similar reference; it
is

> unclear if the CSF would be appropriate here though given the phases
> defined
> there are more operational in nature (although configuration is an
> operational task so maybe).
>
>
> Matthew Coles
> Product Security
>
> BOSE
>
>
> Classified as Public
>
> -----Original Message-----
> From: Wheeler, David A <[hidden email]>
> Sent: Wednesday, January 29, 2020 15:27
> To: Buttner, Drew <[hidden email]>; CWE Research Discussion
> <[hidden email]>
> Subject: RE: [EXT] RE: CWE Configuration Category
>
> Buttner, Drew <[hidden email]> :
> > Thank you for the clarification regarding SDLC.  I think what was
> > meant was that configuration is a part/step of the overall lifecycle of
a

> product.
> ...
> > With this [new] structure, the category "Configuration" doesn't seem to
> fit.
> > ... mis-configurations
> > mostly lead to / create weaknesses that are covered elsewhere in CWE,
> > such as permission problems, cleartext transmission, etc.
>
> Please let me walk through an example of what I *think* you mean, and
> then
> tell me if that's what you meant.
>
> A common configuration failing is a known username/password pair, e.g.,
> "root/root" and "admin/admin" are often set when vendors deliver
> products.
> I think that should be a CWE; for argument let's say it is, as "CWE-XYZ
> Password known by someone other than user".
> Under this regime, I would put CWE-XYZ under "Credentials Management
> Errors"
> (you could argue it's "Authentication Errors" but I think it's really
> credentials management error).
> In the CWE-XYZ text, you would note that the "Mode of Introduction" is
> often
> "configuration".
> That does raise a question - is "mode of introduction" a fixed value for
> each CWE?
>
> Is this what you have in mind?
>
> If so, I think this needs to be discussed somewhere "up front" for people
> who are new to (this version of) the CWE. It *will* be surprising that
there
> aren't CWEs focused on configuration. It might be helpful, in that
> introduction, to note several CWEs that are especially important while
> configuring something.
>
> --- David A. Wheeler

smime.p7s (6K) Download Attachment