SSL Certificates and MAEC

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

SSL Certificates and MAEC

Kirillov, Ivan A.
Hello Everyone,

With the recent Comodo certificate compromise (see http://www.f-secure.com/weblog/archives/00002128.html), the CVE team here at MITRE has been contacted on numerous occasions for the issuance of a CVE against this issue. However, certificates issued by a compromised CA do not represent a software vulnerability in the scope of CVE, and so we were wondering if this is something that can be encompassed by another effort, like MAEC.

Bad certificates are like privilege escalation in that it can enable an attacker or malware to do other things. There have been some interesting discussions of how an adversary could take advantage of this (some are in the f-secure blog post mentioned above).

As such, we've been wondering if we should have the ability to characterize SSL certificates in MAEC. This is a case where it would be useful to have temporal information (knowing when certificates issued by a CA might be invalid), along with general attributes about the certificates.

Some MAEC use cases with regards to SSL certificates would be oriented towards malware detection and attribution. It seems that rogue AV programs in particular like to make use of bad SSL certificates to look legitimate, and so it could be useful to be able to tie these certificates to the malware that they are associated with.

Any thoughts on this? Are there any other use cases you see the inclusion of information about SSL certificates supporting in the MAEC context?

Regards,
Ivan

Ivan Kirillov
MAEC Working Group
The MITRE Corporation
Reply | Threaded
Open this post in threaded view
|

Re: SSL Certificates and MAEC

George Saylor
It sounds like a good idea.  I have seen detection methods aimed at
specific certificates and it seems relevant.

Sent from my iPhone

On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]> wrote:

> Hello Everyone,
>
> With the recent Comodo certificate compromise (see http://www.f-secure.com/weblog/archives/00002128.html), the CVE team here at MITRE has been contacted on numerous occasions for the issuance of a CVE against this issue. However, certificates issued by a compromised CA do not represent a software vulnerability in the scope of CVE, and so we were wondering if this is something that can be encompassed by another effort, like MAEC.
>
> Bad certificates are like privilege escalation in that it can enable an attacker or malware to do other things. There have been some interesting discussions of how an adversary could take advantage of this (some are in the f-secure blog post mentioned above).
>
> As such, we've been wondering if we should have the ability to characterize SSL certificates in MAEC. This is a case where it would be useful to have temporal information (knowing when certificates issued by a CA might be invalid), along with general attributes about the certificates.
>
> Some MAEC use cases with regards to SSL certificates would be oriented towards malware detection and attribution. It seems that rogue AV programs in particular like to make use of bad SSL certificates to look legitimate, and so it could be useful to be able to tie these certificates to the malware that they are associated with.
>
> Any thoughts on this? Are there any other use cases you see the inclusion of information about SSL certificates supporting in the MAEC context?
>
> Regards,
> Ivan
>
> Ivan Kirillov
> MAEC Working Group
> The MITRE Corporation
Reply | Threaded
Open this post in threaded view
|

Re: SSL Certificates and MAEC

Adam Montville
Off the cuff here, I'd like to propose that any consideration of this
moving forward be applied to digital certificates in the abstract, and
X.509 certificates in particular.  We might even take that a step further
and indicate that we're talking about forged/errantly-produced
credentials.  

In this case, are we talking MAEC or CAPEC?

Should there be a CVE (or CVE-like) method for describing a (non-IT)
process vulnerability?

Should there be a configuration setting identifier for certificate stores
holding particular certificates?

This is an interesting problem from an automation perspective, but it
seems like one worth exploring.

Regards,

Adam W. Montville | Compliance and Security Architect





On 4/15/11 1:38 PM, "George Saylor" <[hidden email]> wrote:

>It sounds like a good idea.  I have seen detection methods aimed at
>specific certificates and it seems relevant.
>
>Sent from my iPhone
>
>On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]>
>wrote:
>
>> Hello Everyone,
>>
>> With the recent Comodo certificate compromise (see
>>http://www.f-secure.com/weblog/archives/00002128.html), the CVE team
>>here at MITRE has been contacted on numerous occasions for the issuance
>>of a CVE against this issue. However, certificates issued by a
>>compromised CA do not represent a software vulnerability in the scope of
>>CVE, and so we were wondering if this is something that can be
>>encompassed by another effort, like MAEC.
>>
>> Bad certificates are like privilege escalation in that it can enable an
>>attacker or malware to do other things. There have been some interesting
>>discussions of how an adversary could take advantage of this (some are
>>in the f-secure blog post mentioned above).
>>
>> As such, we've been wondering if we should have the ability to
>>characterize SSL certificates in MAEC. This is a case where it would be
>>useful to have temporal information (knowing when certificates issued by
>>a CA might be invalid), along with general attributes about the
>>certificates.
>>
>> Some MAEC use cases with regards to SSL certificates would be oriented
>>towards malware detection and attribution. It seems that rogue AV
>>programs in particular like to make use of bad SSL certificates to look
>>legitimate, and so it could be useful to be able to tie these
>>certificates to the malware that they are associated with.
>>
>> Any thoughts on this? Are there any other use cases you see the
>>inclusion of information about SSL certificates supporting in the MAEC
>>context?
>>
>> Regards,
>> Ivan
>>
>> Ivan Kirillov
>> MAEC Working Group
>> The MITRE Corporation
>
Reply | Threaded
Open this post in threaded view
|

RE: SSL Certificates and MAEC

Chase, Melissa P.
I agree with you Adam; we should think about this in a broader way. We framed the discussion in terms of X.509 certs because of the specific events, but clearly this is only one type of forged credentials.

The question of CAPEC vs MAEC is an interesting one. My take is that this belongs in both. Higher-level MAEC abstractions should point to CAPEC patterns (one of our goals is to capture behaviors in MAEC). CAPEC represents abstractions of attacks, and MAEC describes implementations of those in malware. MAEC should capture the more specific cases, probably using CybOX (the cyber observables schema shared among CAPEC, CEE, and MAEC) and CAPEC can "decorate" a pattern with those CybOX descriptions. CAPEC should provide a the taxonomy liking forged credentials and specific types of forged credentials.

This, of course raises the question of thinking about this all semantically...

Penny

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Adam Montville
Sent: Friday, April 15, 2011 4:50 PM
To: George Saylor; Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: SSL Certificates and MAEC

Off the cuff here, I'd like to propose that any consideration of this
moving forward be applied to digital certificates in the abstract, and
X.509 certificates in particular.  We might even take that a step further
and indicate that we're talking about forged/errantly-produced
credentials.  

In this case, are we talking MAEC or CAPEC?

Should there be a CVE (or CVE-like) method for describing a (non-IT)
process vulnerability?

Should there be a configuration setting identifier for certificate stores
holding particular certificates?

This is an interesting problem from an automation perspective, but it
seems like one worth exploring.

Regards,

Adam W. Montville | Compliance and Security Architect





On 4/15/11 1:38 PM, "George Saylor" <[hidden email]> wrote:

>It sounds like a good idea.  I have seen detection methods aimed at
>specific certificates and it seems relevant.
>
>Sent from my iPhone
>
>On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]>
>wrote:
>
>> Hello Everyone,
>>
>> With the recent Comodo certificate compromise (see
>>http://www.f-secure.com/weblog/archives/00002128.html), the CVE team
>>here at MITRE has been contacted on numerous occasions for the issuance
>>of a CVE against this issue. However, certificates issued by a
>>compromised CA do not represent a software vulnerability in the scope of
>>CVE, and so we were wondering if this is something that can be
>>encompassed by another effort, like MAEC.
>>
>> Bad certificates are like privilege escalation in that it can enable an
>>attacker or malware to do other things. There have been some interesting
>>discussions of how an adversary could take advantage of this (some are
>>in the f-secure blog post mentioned above).
>>
>> As such, we've been wondering if we should have the ability to
>>characterize SSL certificates in MAEC. This is a case where it would be
>>useful to have temporal information (knowing when certificates issued by
>>a CA might be invalid), along with general attributes about the
>>certificates.
>>
>> Some MAEC use cases with regards to SSL certificates would be oriented
>>towards malware detection and attribution. It seems that rogue AV
>>programs in particular like to make use of bad SSL certificates to look
>>legitimate, and so it could be useful to be able to tie these
>>certificates to the malware that they are associated with.
>>
>> Any thoughts on this? Are there any other use cases you see the
>>inclusion of information about SSL certificates supporting in the MAEC
>>context?
>>
>> Regards,
>> Ivan
>>
>> Ivan Kirillov
>> MAEC Working Group
>> The MITRE Corporation
>
Reply | Threaded
Open this post in threaded view
|

Re: SSL Certificates and MAEC

Adam Montville
Maybe I've been living under a rock, but can you point me to CybOX?

Regards,

Adam W. Montville | Compliance and Security Architect





On 4/15/11 2:01 PM, "Chase, Melissa P." <[hidden email]> wrote:

>I agree with you Adam; we should think about this in a broader way. We
>framed the discussion in terms of X.509 certs because of the specific
>events, but clearly this is only one type of forged credentials.
>
>The question of CAPEC vs MAEC is an interesting one. My take is that this
>belongs in both. Higher-level MAEC abstractions should point to CAPEC
>patterns (one of our goals is to capture behaviors in MAEC). CAPEC
>represents abstractions of attacks, and MAEC describes implementations of
>those in malware. MAEC should capture the more specific cases, probably
>using CybOX (the cyber observables schema shared among CAPEC, CEE, and
>MAEC) and CAPEC can "decorate" a pattern with those CybOX descriptions.
>CAPEC should provide a the taxonomy liking forged credentials and
>specific types of forged credentials.
>
>This, of course raises the question of thinking about this all
>semantically...
>
>Penny
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Adam
>Montville
>Sent: Friday, April 15, 2011 4:50 PM
>To: George Saylor; Kirillov, Ivan A.
>Cc: maec-discussion-list Malware Attribute Enumeration Discussion
>Subject: Re: SSL Certificates and MAEC
>
>Off the cuff here, I'd like to propose that any consideration of this
>moving forward be applied to digital certificates in the abstract, and
>X.509 certificates in particular.  We might even take that a step further
>and indicate that we're talking about forged/errantly-produced
>credentials.  
>
>In this case, are we talking MAEC or CAPEC?
>
>Should there be a CVE (or CVE-like) method for describing a (non-IT)
>process vulnerability?
>
>Should there be a configuration setting identifier for certificate stores
>holding particular certificates?
>
>This is an interesting problem from an automation perspective, but it
>seems like one worth exploring.
>
>Regards,
>
>Adam W. Montville | Compliance and Security Architect
>
>
>
>
>
>On 4/15/11 1:38 PM, "George Saylor" <[hidden email]> wrote:
>
>>It sounds like a good idea.  I have seen detection methods aimed at
>>specific certificates and it seems relevant.
>>
>>Sent from my iPhone
>>
>>On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]>
>>wrote:
>>
>>> Hello Everyone,
>>>
>>> With the recent Comodo certificate compromise (see
>>>http://www.f-secure.com/weblog/archives/00002128.html), the CVE team
>>>here at MITRE has been contacted on numerous occasions for the issuance
>>>of a CVE against this issue. However, certificates issued by a
>>>compromised CA do not represent a software vulnerability in the scope of
>>>CVE, and so we were wondering if this is something that can be
>>>encompassed by another effort, like MAEC.
>>>
>>> Bad certificates are like privilege escalation in that it can enable an
>>>attacker or malware to do other things. There have been some interesting
>>>discussions of how an adversary could take advantage of this (some are
>>>in the f-secure blog post mentioned above).
>>>
>>> As such, we've been wondering if we should have the ability to
>>>characterize SSL certificates in MAEC. This is a case where it would be
>>>useful to have temporal information (knowing when certificates issued by
>>>a CA might be invalid), along with general attributes about the
>>>certificates.
>>>
>>> Some MAEC use cases with regards to SSL certificates would be oriented
>>>towards malware detection and attribution. It seems that rogue AV
>>>programs in particular like to make use of bad SSL certificates to look
>>>legitimate, and so it could be useful to be able to tie these
>>>certificates to the malware that they are associated with.
>>>
>>> Any thoughts on this? Are there any other use cases you see the
>>>inclusion of information about SSL certificates supporting in the MAEC
>>>context?
>>>
>>> Regards,
>>> Ivan
>>>
>>> Ivan Kirillov
>>> MAEC Working Group
>>> The MITRE Corporation
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: SSL Certificates and MAEC

Chase, Melissa P.
A version of CybOX is embedded in CAPEC 1.6. The next major release of MAEC will use CybOX to represent lower-level objects and actions. CybOX defines an object as an abstract element, and then creates concrete defined objects (e.g., file objects, process objects). I think that as we rework MAEC using CybOX, we'll be extending CybOX, e.g., to cover additional defined objects.

If you go to http://capec.mitre.org and follow the 1.6 link, you'll a separate XSD for CybOX (called Observables XSD).

Penny

-----Original Message-----
From: Adam Montville [mailto:[hidden email]]
Sent: Friday, April 15, 2011 5:12 PM
To: Chase, Melissa P.; George Saylor; Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: SSL Certificates and MAEC

Maybe I've been living under a rock, but can you point me to CybOX?

Regards,

Adam W. Montville | Compliance and Security Architect





On 4/15/11 2:01 PM, "Chase, Melissa P." <[hidden email]> wrote:

>I agree with you Adam; we should think about this in a broader way. We
>framed the discussion in terms of X.509 certs because of the specific
>events, but clearly this is only one type of forged credentials.
>
>The question of CAPEC vs MAEC is an interesting one. My take is that this
>belongs in both. Higher-level MAEC abstractions should point to CAPEC
>patterns (one of our goals is to capture behaviors in MAEC). CAPEC
>represents abstractions of attacks, and MAEC describes implementations of
>those in malware. MAEC should capture the more specific cases, probably
>using CybOX (the cyber observables schema shared among CAPEC, CEE, and
>MAEC) and CAPEC can "decorate" a pattern with those CybOX descriptions.
>CAPEC should provide a the taxonomy liking forged credentials and
>specific types of forged credentials.
>
>This, of course raises the question of thinking about this all
>semantically...
>
>Penny
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Adam
>Montville
>Sent: Friday, April 15, 2011 4:50 PM
>To: George Saylor; Kirillov, Ivan A.
>Cc: maec-discussion-list Malware Attribute Enumeration Discussion
>Subject: Re: SSL Certificates and MAEC
>
>Off the cuff here, I'd like to propose that any consideration of this
>moving forward be applied to digital certificates in the abstract, and
>X.509 certificates in particular.  We might even take that a step further
>and indicate that we're talking about forged/errantly-produced
>credentials.  
>
>In this case, are we talking MAEC or CAPEC?
>
>Should there be a CVE (or CVE-like) method for describing a (non-IT)
>process vulnerability?
>
>Should there be a configuration setting identifier for certificate stores
>holding particular certificates?
>
>This is an interesting problem from an automation perspective, but it
>seems like one worth exploring.
>
>Regards,
>
>Adam W. Montville | Compliance and Security Architect
>
>
>
>
>
>On 4/15/11 1:38 PM, "George Saylor" <[hidden email]> wrote:
>
>>It sounds like a good idea.  I have seen detection methods aimed at
>>specific certificates and it seems relevant.
>>
>>Sent from my iPhone
>>
>>On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]>
>>wrote:
>>
>>> Hello Everyone,
>>>
>>> With the recent Comodo certificate compromise (see
>>>http://www.f-secure.com/weblog/archives/00002128.html), the CVE team
>>>here at MITRE has been contacted on numerous occasions for the issuance
>>>of a CVE against this issue. However, certificates issued by a
>>>compromised CA do not represent a software vulnerability in the scope of
>>>CVE, and so we were wondering if this is something that can be
>>>encompassed by another effort, like MAEC.
>>>
>>> Bad certificates are like privilege escalation in that it can enable an
>>>attacker or malware to do other things. There have been some interesting
>>>discussions of how an adversary could take advantage of this (some are
>>>in the f-secure blog post mentioned above).
>>>
>>> As such, we've been wondering if we should have the ability to
>>>characterize SSL certificates in MAEC. This is a case where it would be
>>>useful to have temporal information (knowing when certificates issued by
>>>a CA might be invalid), along with general attributes about the
>>>certificates.
>>>
>>> Some MAEC use cases with regards to SSL certificates would be oriented
>>>towards malware detection and attribution. It seems that rogue AV
>>>programs in particular like to make use of bad SSL certificates to look
>>>legitimate, and so it could be useful to be able to tie these
>>>certificates to the malware that they are associated with.
>>>
>>> Any thoughts on this? Are there any other use cases you see the
>>>inclusion of information about SSL certificates supporting in the MAEC
>>>context?
>>>
>>> Regards,
>>> Ivan
>>>
>>> Ivan Kirillov
>>> MAEC Working Group
>>> The MITRE Corporation
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SSL Certificates and MAEC

Tony Rutkowski
In reply to this post by George Saylor
Hi all,

During the course of our CYBEX standards work
at ITU-T that I chair and which includes MAEC,
we have suggested the use of EVcerts as ubiquitously
as possible for all objects.  The parent organization for
EVcert specs, the CABrowser Forum, is a very active
body that is constantly evaluating and advancing use of
both the technical and non-technical assurance mechanisms.

--tony
Reply | Threaded
Open this post in threaded view
|

RE: SSL Certificates and MAEC

Nathan Christiansen
In reply to this post by George Saylor
I had posting issues the first time around so here I go for a second time:


I think it could fit (in the case of the MAEC) into the type of stealth technology used.

It can also be classified as a technology-based method of social engineering.

The details of the issued certificate (footprint, CA, etc.) that allow for automated detection can then be integrated into the MAEC Schema.


-- Nathan Christiansen


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of George Saylor
Sent: Friday, April 15, 2011 2:39 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: SSL Certificates and MAEC

It sounds like a good idea.  I have seen detection methods aimed at
specific certificates and it seems relevant.

Sent from my iPhone

On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]> wrote:

> Hello Everyone,
>
> With the recent Comodo certificate compromise (see http://www.f-secure.com/weblog/archives/00002128.html), the CVE team here at MITRE has been contacted on numerous occasions for the issuance of a CVE against this issue. However, certificates issued by a compromised CA do not represent a software vulnerability in the scope of CVE, and so we were wondering if this is something that can be encompassed by another effort, like MAEC.
>
> Bad certificates are like privilege escalation in that it can enable an attacker or malware to do other things. There have been some interesting discussions of how an adversary could take advantage of this (some are in the f-secure blog post mentioned above).
>
> As such, we've been wondering if we should have the ability to characterize SSL certificates in MAEC. This is a case where it would be useful to have temporal information (knowing when certificates issued by a CA might be invalid), along with general attributes about the certificates.
>
> Some MAEC use cases with regards to SSL certificates would be oriented towards malware detection and attribution. It seems that rogue AV programs in particular like to make use of bad SSL certificates to look legitimate, and so it could be useful to be able to tie these certificates to the malware that they are associated with.
>
> Any thoughts on this? Are there any other use cases you see the inclusion of information about SSL certificates supporting in the MAEC context?
>
> Regards,
> Ivan
>
> Ivan Kirillov
> MAEC Working Group
> The MITRE Corporation
Reply | Threaded
Open this post in threaded view
|

RE: SSL Certificates and MAEC

Thomas.Millar
The primitive at hand seems to me to be equivalent to assuming the guise
of a trusted professional (e.g. pizza courier, police officer,
housecleaning staff, etc.) (which would fall under spoofing and social
engineering as CAPEC methods of attack, not to mention the supply chain
problem of how the "uniforms" were distributed), and to carry the
metaphor further, the "BOLO" going out as a result might boil down to
asking all potential victims to lower their usual confidence in whatever
credential scheme is being abused. The RSA fallout produced similar
doubts in a previously trusted credential set.

So there's two main ideas that a CSIRT would need to broadcast for this:

1. a detailed observable, if one is known, so that bad credentials can
be automatically flagged or blocked as appropriate; and

2. more abstract guidance to the effect that credentials of this type
(certs or tokens or badges or whatever) demand a closer look, or more
layers of risk management, than previously assumed.

The first is certainly within the scope of structured, machine-readable
information formats and languages. The second, I'm not so sure -
especially where the "supply chain" of a credential starts to resemble a
system of systems and begins involving the marketplace, I believe nuance
is going to be in high demand, and any remediation recommendations that
are applied are unlikely to be the sort that can be automatically
validated.



 - Tom Millar, US-CERT

[hidden email]
BB: [hidden email] / 202-631-1915
24x7: [hidden email] / 888-282-0870
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Nathan
Christiansen
Sent: Tuesday, April 19, 2011 2:58 PM
To: [hidden email]
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: RE: SSL Certificates and MAEC

I had posting issues the first time around so here I go for a second
time:


I think it could fit (in the case of the MAEC) into the type of stealth
technology used.

It can also be classified as a technology-based method of social
engineering.

The details of the issued certificate (footprint, CA, etc.) that allow
for automated detection can then be integrated into the MAEC Schema.


-- Nathan Christiansen


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of George
Saylor
Sent: Friday, April 15, 2011 2:39 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: SSL Certificates and MAEC

It sounds like a good idea.  I have seen detection methods aimed at
specific certificates and it seems relevant.

Sent from my iPhone

On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]>
wrote:

> Hello Everyone,
>
> With the recent Comodo certificate compromise (see
http://www.f-secure.com/weblog/archives/00002128.html), the CVE team
here at MITRE has been contacted on numerous occasions for the issuance
of a CVE against this issue. However, certificates issued by a
compromised CA do not represent a software vulnerability in the scope of
CVE, and so we were wondering if this is something that can be
encompassed by another effort, like MAEC.
>
> Bad certificates are like privilege escalation in that it can enable
an attacker or malware to do other things. There have been some
interesting discussions of how an adversary could take advantage of this
(some are in the f-secure blog post mentioned above).
>
> As such, we've been wondering if we should have the ability to
characterize SSL certificates in MAEC. This is a case where it would be
useful to have temporal information (knowing when certificates issued by
a CA might be invalid), along with general attributes about the
certificates.
>
> Some MAEC use cases with regards to SSL certificates would be oriented
towards malware detection and attribution. It seems that rogue AV
programs in particular like to make use of bad SSL certificates to look
legitimate, and so it could be useful to be able to tie these
certificates to the malware that they are associated with.
>
> Any thoughts on this? Are there any other use cases you see the
inclusion of information about SSL certificates supporting in the MAEC
context?
>
> Regards,
> Ivan
>
> Ivan Kirillov
> MAEC Working Group
> The MITRE Corporation
Reply | Threaded
Open this post in threaded view
|

RE: SSL Certificates and MAEC

Kirillov, Ivan A.
Wow, some great discussion on this topic. I think there are a few takeaways from my perspective:

-We need to cover the detailed observables relating to X.509 certs (and perhaps abstract certificates) in the Cyber Observables (CybOX) schema, in order to ensure that this data can be used and correlated across MAEC (malware) and CAPEC (attack patterns)

-The usage of such methods of forged credentials can likely be abstracted to the higher levels of MAEC. This needs further investigation, which will likely transpire after the release of the next MAEC version

-There may be a need for a new standard or other mechanism for relating and assigning identifiers to these kinds of issues, along with any possible remediations associated. This could be tricky to automate, and ascertaining the effectiveness of the remediation may require some human, nuanced judgment.

I do expect that we'll cover X.509 certs (along with Authenticode for digitally signed binaries) at the observable level in CybOX/MAEC 2.0. More about the next MAEC release and our plans for it soon.

Regards,
Ivan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, April 19, 2011 6:44 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: RE: SSL Certificates and MAEC

The primitive at hand seems to me to be equivalent to assuming the guise
of a trusted professional (e.g. pizza courier, police officer,
housecleaning staff, etc.) (which would fall under spoofing and social
engineering as CAPEC methods of attack, not to mention the supply chain
problem of how the "uniforms" were distributed), and to carry the
metaphor further, the "BOLO" going out as a result might boil down to
asking all potential victims to lower their usual confidence in whatever
credential scheme is being abused. The RSA fallout produced similar
doubts in a previously trusted credential set.

So there's two main ideas that a CSIRT would need to broadcast for this:

1. a detailed observable, if one is known, so that bad credentials can
be automatically flagged or blocked as appropriate; and

2. more abstract guidance to the effect that credentials of this type
(certs or tokens or badges or whatever) demand a closer look, or more
layers of risk management, than previously assumed.

The first is certainly within the scope of structured, machine-readable
information formats and languages. The second, I'm not so sure -
especially where the "supply chain" of a credential starts to resemble a
system of systems and begins involving the marketplace, I believe nuance
is going to be in high demand, and any remediation recommendations that
are applied are unlikely to be the sort that can be automatically
validated.



 - Tom Millar, US-CERT

[hidden email]
BB: [hidden email] / 202-631-1915
24x7: [hidden email] / 888-282-0870
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Nathan
Christiansen
Sent: Tuesday, April 19, 2011 2:58 PM
To: [hidden email]
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: RE: SSL Certificates and MAEC

I had posting issues the first time around so here I go for a second
time:


I think it could fit (in the case of the MAEC) into the type of stealth
technology used.

It can also be classified as a technology-based method of social
engineering.

The details of the issued certificate (footprint, CA, etc.) that allow
for automated detection can then be integrated into the MAEC Schema.


-- Nathan Christiansen


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of George
Saylor
Sent: Friday, April 15, 2011 2:39 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: SSL Certificates and MAEC

It sounds like a good idea.  I have seen detection methods aimed at
specific certificates and it seems relevant.

Sent from my iPhone

On Apr 15, 2011, at 4:20 PM, "Kirillov, Ivan A." <[hidden email]>
wrote:

> Hello Everyone,
>
> With the recent Comodo certificate compromise (see
http://www.f-secure.com/weblog/archives/00002128.html), the CVE team
here at MITRE has been contacted on numerous occasions for the issuance
of a CVE against this issue. However, certificates issued by a
compromised CA do not represent a software vulnerability in the scope of
CVE, and so we were wondering if this is something that can be
encompassed by another effort, like MAEC.
>
> Bad certificates are like privilege escalation in that it can enable
an attacker or malware to do other things. There have been some
interesting discussions of how an adversary could take advantage of this
(some are in the f-secure blog post mentioned above).
>
> As such, we've been wondering if we should have the ability to
characterize SSL certificates in MAEC. This is a case where it would be
useful to have temporal information (knowing when certificates issued by
a CA might be invalid), along with general attributes about the
certificates.
>
> Some MAEC use cases with regards to SSL certificates would be oriented
towards malware detection and attribution. It seems that rogue AV
programs in particular like to make use of bad SSL certificates to look
legitimate, and so it could be useful to be able to tie these
certificates to the malware that they are associated with.
>
> Any thoughts on this? Are there any other use cases you see the
inclusion of information about SSL certificates supporting in the MAEC
context?
>
> Regards,
> Ivan
>
> Ivan Kirillov
> MAEC Working Group
> The MITRE Corporation