subject:"Vulnurability Disclosure \- How does it happen\?"

Re: Vulnurability Disclosure - How does it happen?

2024-05-30 Thread Wayne

To bring this discussion back up what is the required impact for 
disclosure? To move the discussion away from Chunghwa Telecom, there also 
was Lockbit ransomware deployed at Entrust in June '22 and at least 400GB+ 
data exfiltrated. We have not had a public report of what data relevant to 
CA operations was obtained. Although correct me if I am wrong I've not 
delved that deeply into the subject.

Keeping to the technical level and leaving the minefield of personal 
information to the side for this discussion... 

What aspects of the CA operation must be impacted for this to be a 
notifiable event? Presumably anything directly impacting the HSMs, 
certificate's private keys, or issuance. How many steps removed from that 
process is fine?

Moving to indirect security aspects, would this also apply to pentest 
reports on the CA infrastructure? I'd presume there's also a lot of 
information generated in Webtrust or ETSI audits that would also be 
material to the security environment.

Given this is a recent real world scenario I think it would be a good 
example to work through.

On Saturday, May 25, 2024 at 11:25:09 AM UTC+1 Li-Chun CHEN wrote:

> Our company's CA system is independent of telecommunications system. There 
> is no impact on Chunghwa Telecom's CA System related to that data breach 
> news. Chunghwa Telecom will continue to strengthen the system & network 
> security control of the CA system to ensure data security. Thank you.
>
>Li-Chun Chen
>Chunghwa Telecom
>
>
> Amir Omidi (aaomidi) 在 2024年5月24日 星期五凌晨1:59:33 [UTC+8] 的信中寫道：
>
> Thanks. I guess this question then is aimed at Chunghwa Telecom to let us 
> know if what's been reported has had any impact on their CA systems.
>
> On Thursday, May 23, 2024 at 1:07:39 PM UTC-4 Ben Wilson wrote:
>
> Amir,
> To answer the last question first, Chunghwa Telecom did not disclose this 
> recent attack, but I don't think we have sufficient information from the 
> article to determine the effects of the breach on the CA operations. So 
> without more information, it might be premature to answer the question, "Is 
> a security incident like the one I posted above considered an instance of a 
> CA "failing to comply"?" 
> The process envisioned by the policy and guidance does contemplate that 
> these disclosures would be in a secure bug (to which Mozilla would grant 
> other root programs access). It also contemplates that another, public bug 
> would need to be created, using the incident-reporting template (including 
> a description of the CA's incident response). Finally, because this is a 
> new process, we do not yet have any experiences to share or to use in 
> evaluating the success or shortcomings of the requirement.
> Ben 
>
> On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via 
> dev-secur...@mozilla.org  wrote:
>
> Hey folks,
>
> I am bringing this up because of: 
> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>
> (I've marked my questions in bold)
>
> I'm mainly basing this discussion around: 
> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to 
> understand what the intent of some of the wording in this is, and how it 
> applies to CAs.
>
> In that wiki, we see:
>
> > Vulnerabilities/incidents that may “significantly impact the 
> confidentiality, integrity, or availability” of a CA's internal systems, 
> regardless of direct impact on certificate issuance, must be reported if 
> they pose ongoing risk to the overall integrity and security of CA 
> operations. This includes significant impact not just to issuing systems, 
> but also to network and server security, internal software, and the 
> availability and reliability of certificate status services, such as CRLs 
> and OCSP.
>
> What is Mozilla's intent by the phrase "must be reported if they pose 
> ongoing risk to the overall integrity and security of CA operations."
>
> More specifically:
>
>1. *"Disclosed" to whom? Public? Just Mozilla?*
>2. *What does "if they pose an ongoing risk" mean? If its a one-off 
>attack, does that mean it does not need to be disclosed?*
>
> I'm also unsure about trusting CAs to determine the significance of such 
> an attack. We've seen recently that a few CAs have really jumped to making 
> claims such as "this incident has no security impact" before doing any 
> proper RCA or even understanding the extent of the incident. *Has Mozilla 
> found any issues with leaving the determination up to CAs in the past?*
>
> More broadly, how does this wiki work when read in conjunction with the 
> Mozilla 
> Root Store Policy 
> 
>
> Specifically, section 2.4:
>
> > When a CA operator fails to comply with any requirement of this policy - 
> whether it be a misissuance, a procedural or operational issue, or any 
> other variety of non-compliance - the event is classified as an

Re: Vulnurability Disclosure - How does it happen?

2024-05-25 Thread Li-Chun CHEN

Our company's CA system is independent of telecommunications system. There
is no impact on Chunghwa Telecom's CA System related to that data breach
news. Chunghwa Telecom will continue to strengthen the system & network
security control of the CA system to ensure data security. Thank you.

Li-Chun Chen
Chunghwa Telecom

Amir Omidi (aaomidi) 在 2024年5月24日 星期五凌晨1:59:33 [UTC+8] 的信中寫道：

Thanks. I guess this question then is aimed at Chunghwa Telecom to let us
know if what's been reported has had any impact on their CA systems.

On Thursday, May 23, 2024 at 1:07:39 PM UTC-4 Ben Wilson wrote:

Amir,
To answer the last question first, Chunghwa Telecom did not disclose this
recent attack, but I don't think we have sufficient information from the
article to determine the effects of the breach on the CA operations. So
without more information, it might be premature to answer the question, "Is
a security incident like the one I posted above considered an instance of a
CA "failing to comply"?"
The process envisioned by the policy and guidance does contemplate that
these disclosures would be in a secure bug (to which Mozilla would grant
other root programs access). It also contemplates that another, public bug
would need to be created, using the incident-reporting template (including
a description of the CA's incident response). Finally, because this is a
new process, we do not yet have any experiences to share or to use in
evaluating the success or shortcomings of the requirement.
Ben

On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via
dev-secur...@mozilla.org wrote:

Hey folks,

I am bringing this up because of:
https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web

(I've marked my questions in bold)

I'm mainly basing this discussion around:
https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to understand
what the intent of some of the wording in this is, and how it applies to
CAs.

In that wiki, we see:

> Vulnerabilities/incidents that may “significantly impact the
confidentiality, integrity, or availability” of a CA's internal systems,
regardless of direct impact on certificate issuance, must be reported if
they pose ongoing risk to the overall integrity and security of CA
operations. This includes significant impact not just to issuing systems,
but also to network and server security, internal software, and the
availability and reliability of certificate status services, such as CRLs
and OCSP.

What is Mozilla's intent by the phrase "must be reported if they pose
ongoing risk to the overall integrity and security of CA operations."

More specifically:

1. *"Disclosed" to whom? Public? Just Mozilla?*
2. *What does "if they pose an ongoing risk" mean? If its a one-off
attack, does that mean it does not need to be disclosed?*

I'm also unsure about trusting CAs to determine the significance of such an
attack. We've seen recently that a few CAs have really jumped to making
claims such as "this incident has no security impact" before doing any
proper RCA or even understanding the extent of the incident. *Has Mozilla
found any issues with leaving the determination up to CAs in the past?*

More broadly, how does this wiki work when read in conjunction with the Mozilla
Root Store Policy

Specifically, section 2.4:

> When a CA operator fails to comply with any requirement of this policy -
whether it be a misissuance, a procedural or operational issue, or any
other variety of non-compliance - the event is classified as an incident
and MUST be reported to Mozilla as soon as the CA operator is made aware.

*Is a security incident like the one I posted above considered an instance
of a CA "failing to comply"?*

In 2.4.1 we see:

> Additionally, and not in lieu of the requirement to publicly report
incidents as outlined above, a CA Operator MUST disclose a serious
vulnerability or security incident in Bugzilla
as a secure bug

in accordance with guidance found on the Vulnerability Disclosure wiki page
.

>From my reading here, this means that all security vulnerabilities are
being disclosed privately to Mozilla. I guess this *kind of* makes sense
here.

*Would Mozilla be open to having a limited cooling-off period where these
secure bugs stay private, but after that period the information becomes
public*?

My justification for asking this is:

Re: Vulnurability Disclosure - How does it happen?

2024-05-23 Thread 'Aaron Gable' via dev-security-policy@mozilla.org

Although it was not the result of a security breach or other directed
attack, I can provide this bugzilla bug
 as an example of
what an embargoed incident report followed by public disclosure has looked
like in the past.

Aaron

On Thu, May 23, 2024 at 10:59 AM 'Amir Omidi (aaomidi)' via
dev-security-policy@mozilla.org  wrote:

> Thanks. I guess this question then is aimed at Chunghwa Telecom to let us
> know if what's been reported has had any impact on their CA systems.
>
> On Thursday, May 23, 2024 at 1:07:39 PM UTC-4 Ben Wilson wrote:
>
>> Amir,
>> To answer the last question first, Chunghwa Telecom did not disclose this
>> recent attack, but I don't think we have sufficient information from the
>> article to determine the effects of the breach on the CA operations. So
>> without more information, it might be premature to answer the question, "Is
>> a security incident like the one I posted above considered an instance of a
>> CA "failing to comply"?"
>> The process envisioned by the policy and guidance does contemplate that
>> these disclosures would be in a secure bug (to which Mozilla would grant
>> other root programs access). It also contemplates that another, public bug
>> would need to be created, using the incident-reporting template (including
>> a description of the CA's incident response). Finally, because this is a
>> new process, we do not yet have any experiences to share or to use in
>> evaluating the success or shortcomings of the requirement.
>> Ben
>>
>> On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via
>> dev-secur...@mozilla.org  wrote:
>>
>>> Hey folks,
>>>
>>> I am bringing this up because of:
>>> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>>>
>>> (I've marked my questions in bold)
>>>
>>> I'm mainly basing this discussion around:
>>> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to
>>> understand what the intent of some of the wording in this is, and how it
>>> applies to CAs.
>>>
>>> In that wiki, we see:
>>>
>>> > Vulnerabilities/incidents that may “significantly impact the
>>> confidentiality, integrity, or availability” of a CA's internal systems,
>>> regardless of direct impact on certificate issuance, must be reported if
>>> they pose ongoing risk to the overall integrity and security of CA
>>> operations. This includes significant impact not just to issuing systems,
>>> but also to network and server security, internal software, and the
>>> availability and reliability of certificate status services, such as CRLs
>>> and OCSP.
>>>
>>> What is Mozilla's intent by the phrase "must be reported if they pose
>>> ongoing risk to the overall integrity and security of CA operations."
>>>
>>> More specifically:
>>>
>>>1. *"Disclosed" to whom? Public? Just Mozilla?*
>>>2. *What does "if they pose an ongoing risk" mean? If its a one-off
>>>attack, does that mean it does not need to be disclosed?*
>>>
>>> I'm also unsure about trusting CAs to determine the significance of such
>>> an attack. We've seen recently that a few CAs have really jumped to making
>>> claims such as "this incident has no security impact" before doing any
>>> proper RCA or even understanding the extent of the incident. *Has
>>> Mozilla found any issues with leaving the determination up to CAs in the
>>> past?*
>>>
>>> More broadly, how does this wiki work when read in conjunction with the 
>>> Mozilla
>>> Root Store Policy
>>> 
>>>
>>> Specifically, section 2.4:
>>>
>>> > When a CA operator fails to comply with any requirement of this policy
>>> - whether it be a misissuance, a procedural or operational issue, or any
>>> other variety of non-compliance - the event is classified as an incident
>>> and MUST be reported to Mozilla as soon as the CA operator is made aware.
>>>
>>> *Is a security incident like the one I posted above considered an
>>> instance of a CA "failing to comply"?*
>>>
>>> In 2.4.1 we see:
>>>
>>> > Additionally, and not in lieu of the requirement to publicly report
>>> incidents as outlined above, a CA Operator MUST disclose a serious
>>> vulnerability or security incident in Bugzilla
>>>  as a secure bug
>>> 
>>> in accordance with guidance found on the Vulnerability Disclosure wiki
>>> page .
>>>
>>> From my reading here, this means that all security vulnerabilities are
>>> being disclosed privately to Mozilla. I guess this *kind of* makes
>>> sense here.
>>>
>>> *Would Mozilla be open to having a limited cooling-off period where
>>> these secure bugs stay private, but after that period the information
>>> becomes public*?
>>>
>>> My justification for asking

Re: Vulnurability Disclosure - How does it happen?

2024-05-23 Thread 'Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org

Thanks. I guess this question then is aimed at Chunghwa Telecom to let us 
know if what's been reported has had any impact on their CA systems.

On Thursday, May 23, 2024 at 1:07:39 PM UTC-4 Ben Wilson wrote:

> Amir,
> To answer the last question first, Chunghwa Telecom did not disclose this 
> recent attack, but I don't think we have sufficient information from the 
> article to determine the effects of the breach on the CA operations. So 
> without more information, it might be premature to answer the question, "Is 
> a security incident like the one I posted above considered an instance of a 
> CA "failing to comply"?" 
> The process envisioned by the policy and guidance does contemplate that 
> these disclosures would be in a secure bug (to which Mozilla would grant 
> other root programs access). It also contemplates that another, public bug 
> would need to be created, using the incident-reporting template (including 
> a description of the CA's incident response). Finally, because this is a 
> new process, we do not yet have any experiences to share or to use in 
> evaluating the success or shortcomings of the requirement.
> Ben 
>
> On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via 
> dev-secur...@mozilla.org  wrote:
>
>> Hey folks,
>>
>> I am bringing this up because of: 
>> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>>
>> (I've marked my questions in bold)
>>
>> I'm mainly basing this discussion around: 
>> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to 
>> understand what the intent of some of the wording in this is, and how it 
>> applies to CAs.
>>
>> In that wiki, we see:
>>
>> > Vulnerabilities/incidents that may “significantly impact the 
>> confidentiality, integrity, or availability” of a CA's internal systems, 
>> regardless of direct impact on certificate issuance, must be reported if 
>> they pose ongoing risk to the overall integrity and security of CA 
>> operations. This includes significant impact not just to issuing systems, 
>> but also to network and server security, internal software, and the 
>> availability and reliability of certificate status services, such as CRLs 
>> and OCSP.
>>
>> What is Mozilla's intent by the phrase "must be reported if they pose 
>> ongoing risk to the overall integrity and security of CA operations."
>>
>> More specifically:
>>
>>1. *"Disclosed" to whom? Public? Just Mozilla?*
>>2. *What does "if they pose an ongoing risk" mean? If its a one-off 
>>attack, does that mean it does not need to be disclosed?*
>>
>> I'm also unsure about trusting CAs to determine the significance of such 
>> an attack. We've seen recently that a few CAs have really jumped to making 
>> claims such as "this incident has no security impact" before doing any 
>> proper RCA or even understanding the extent of the incident. *Has 
>> Mozilla found any issues with leaving the determination up to CAs in the 
>> past?*
>>
>> More broadly, how does this wiki work when read in conjunction with the 
>> Mozilla 
>> Root Store Policy 
>> 
>>
>> Specifically, section 2.4:
>>
>> > When a CA operator fails to comply with any requirement of this policy 
>> - whether it be a misissuance, a procedural or operational issue, or any 
>> other variety of non-compliance - the event is classified as an incident 
>> and MUST be reported to Mozilla as soon as the CA operator is made aware.
>>
>> *Is a security incident like the one I posted above considered an 
>> instance of a CA "failing to comply"?*
>>
>> In 2.4.1 we see:
>>
>> > Additionally, and not in lieu of the requirement to publicly report 
>> incidents as outlined above, a CA Operator MUST disclose a serious 
>> vulnerability or security incident in Bugzilla 
>>  as a secure bug 
>> 
>>  
>> in accordance with guidance found on the Vulnerability Disclosure wiki 
>> page .
>>
>> From my reading here, this means that all security vulnerabilities are 
>> being disclosed privately to Mozilla. I guess this *kind of* makes sense 
>> here.
>>
>> *Would Mozilla be open to having a limited cooling-off period where these 
>> secure bugs stay private, but after that period the information becomes 
>> public*?
>>
>> My justification for asking this is:
>>
>>- Other CAs can and should learn from how a CA responded to a 
>>security incident.
>>- There may be commonalities in attack patterns that these incidents 
>>being public can help surface.
>>- It reassures the community that these incidents are being taken 
>>seriously by allowing third parties to also verify and validate the 
>>incident response and mitigation items.
>>
>>
>> Beyond

Re: Vulnurability Disclosure - How does it happen?

2024-05-23 Thread 'Ben Wilson' via dev-security-policy@mozilla.org

Amir,
To answer the last question first, Chunghwa Telecom did not disclose this
recent attack, but I don't think we have sufficient information from the
article to determine the effects of the breach on the CA operations. So
without more information, it might be premature to answer the question, "Is
a security incident like the one I posted above considered an instance of a
CA "failing to comply"?"
The process envisioned by the policy and guidance does contemplate that
these disclosures would be in a secure bug (to which Mozilla would grant
other root programs access). It also contemplates that another, public bug
would need to be created, using the incident-reporting template (including
a description of the CA's incident response). Finally, because this is a
new process, we do not yet have any experiences to share or to use in
evaluating the success or shortcomings of the requirement.
Ben

On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via
dev-security-policy@mozilla.org  wrote:

> Hey folks,
>
> I am bringing this up because of:
> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>
> (I've marked my questions in bold)
>
> I'm mainly basing this discussion around:
> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to
> understand what the intent of some of the wording in this is, and how it
> applies to CAs.
>
> In that wiki, we see:
>
> > Vulnerabilities/incidents that may “significantly impact the
> confidentiality, integrity, or availability” of a CA's internal systems,
> regardless of direct impact on certificate issuance, must be reported if
> they pose ongoing risk to the overall integrity and security of CA
> operations. This includes significant impact not just to issuing systems,
> but also to network and server security, internal software, and the
> availability and reliability of certificate status services, such as CRLs
> and OCSP.
>
> What is Mozilla's intent by the phrase "must be reported if they pose
> ongoing risk to the overall integrity and security of CA operations."
>
> More specifically:
>
>1. *"Disclosed" to whom? Public? Just Mozilla?*
>2. *What does "if they pose an ongoing risk" mean? If its a one-off
>attack, does that mean it does not need to be disclosed?*
>
> I'm also unsure about trusting CAs to determine the significance of such
> an attack. We've seen recently that a few CAs have really jumped to making
> claims such as "this incident has no security impact" before doing any
> proper RCA or even understanding the extent of the incident. *Has Mozilla
> found any issues with leaving the determination up to CAs in the past?*
>
> More broadly, how does this wiki work when read in conjunction with the 
> Mozilla
> Root Store Policy
> 
>
> Specifically, section 2.4:
>
> > When a CA operator fails to comply with any requirement of this policy -
> whether it be a misissuance, a procedural or operational issue, or any
> other variety of non-compliance - the event is classified as an incident
> and MUST be reported to Mozilla as soon as the CA operator is made aware.
>
> *Is a security incident like the one I posted above considered an instance
> of a CA "failing to comply"?*
>
> In 2.4.1 we see:
>
> > Additionally, and not in lieu of the requirement to publicly report
> incidents as outlined above, a CA Operator MUST disclose a serious
> vulnerability or security incident in Bugzilla
>  as a secure bug
> 
> in accordance with guidance found on the Vulnerability Disclosure wiki
> page .
>
> From my reading here, this means that all security vulnerabilities are
> being disclosed privately to Mozilla. I guess this *kind of* makes sense
> here.
>
> *Would Mozilla be open to having a limited cooling-off period where these
> secure bugs stay private, but after that period the information becomes
> public*?
>
> My justification for asking this is:
>
>- Other CAs can and should learn from how a CA responded to a security
>incident.
>- There may be commonalities in attack patterns that these incidents
>being public can help surface.
>- It reassures the community that these incidents are being taken
>seriously by allowing third parties to also verify and validate the
>incident response and mitigation items.
>
>
> Beyond this, *I'd also be interested in hearing if Chunghwa Telecom has
> disclosed the impact of this recent attack on their systems (if any) to
> Mozilla and the other root programs.*
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
>

Re: Vulnurability Disclosure - How does it happen?

2024-05-23 Thread Mike Shaver

Historically at least, Mozilla secure bugs are kept closed only while
publishing the information would itself be harmful to the security of
Mozilla’s users or others on the web. Relevant patches are out, etc. We
held fuzzing tools back for a year or so because another major browser had
a hard time getting all the exposed bugs sorted out, at the limit.

I’m not sure how to map that into the CA-breach case, tbh. There usually
isn’t *public* harm that results from the world knowing that someone has
been breached. Or maybe there is, and I’m just not thinking of it?

Mike

On Thu, May 23, 2024 at 11:54 AM 'Amir Omidi (aaomidi)' via
dev-security-policy@mozilla.org  wrote:

> Hey folks,
>
> I am bringing this up because of:
> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>
> (I've marked my questions in bold)
>
> I'm mainly basing this discussion around:
> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to
> understand what the intent of some of the wording in this is, and how it
> applies to CAs.
>
> In that wiki, we see:
>
> > Vulnerabilities/incidents that may “significantly impact the
> confidentiality, integrity, or availability” of a CA's internal systems,
> regardless of direct impact on certificate issuance, must be reported if
> they pose ongoing risk to the overall integrity and security of CA
> operations. This includes significant impact not just to issuing systems,
> but also to network and server security, internal software, and the
> availability and reliability of certificate status services, such as CRLs
> and OCSP.
>
> What is Mozilla's intent by the phrase "must be reported if they pose
> ongoing risk to the overall integrity and security of CA operations."
>
> More specifically:
>
>1. *"Disclosed" to whom? Public? Just Mozilla?*
>2. *What does "if they pose an ongoing risk" mean? If its a one-off
>attack, does that mean it does not need to be disclosed?*
>
> I'm also unsure about trusting CAs to determine the significance of such
> an attack. We've seen recently that a few CAs have really jumped to making
> claims such as "this incident has no security impact" before doing any
> proper RCA or even understanding the extent of the incident. *Has Mozilla
> found any issues with leaving the determination up to CAs in the past?*
>
> More broadly, how does this wiki work when read in conjunction with the 
> Mozilla
> Root Store Policy
> 
>
> Specifically, section 2.4:
>
> > When a CA operator fails to comply with any requirement of this policy -
> whether it be a misissuance, a procedural or operational issue, or any
> other variety of non-compliance - the event is classified as an incident
> and MUST be reported to Mozilla as soon as the CA operator is made aware.
>
> *Is a security incident like the one I posted above considered an instance
> of a CA "failing to comply"?*
>
> In 2.4.1 we see:
>
> > Additionally, and not in lieu of the requirement to publicly report
> incidents as outlined above, a CA Operator MUST disclose a serious
> vulnerability or security incident in Bugzilla
>  as a secure bug
> 
> in accordance with guidance found on the Vulnerability Disclosure wiki
> page .
>
> From my reading here, this means that all security vulnerabilities are
> being disclosed privately to Mozilla. I guess this *kind of* makes sense
> here.
>
> *Would Mozilla be open to having a limited cooling-off period where these
> secure bugs stay private, but after that period the information becomes
> public*?
>
> My justification for asking this is:
>
>- Other CAs can and should learn from how a CA responded to a security
>incident.
>- There may be commonalities in attack patterns that these incidents
>being public can help surface.
>- It reassures the community that these incidents are being taken
>seriously by allowing third parties to also verify and validate the
>incident response and mitigation items.
>
>
> Beyond this, *I'd also be interested in hearing if Chunghwa Telecom has
> disclosed the impact of this recent attack on their systems (if any) to
> Mozilla and the other root programs.*
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b9fa92df-2d48-4740-988c-a147285e181dn%40mozilla.org
>

Vulnurability Disclosure - How does it happen?

2024-05-23 Thread 'Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org

Hey folks,

I am bringing this up because of:
https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web

(I've marked my questions in bold)

I'm mainly basing this discussion around:
https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to understand
what the intent of some of the wording in this is, and how it applies to
CAs.

In that wiki, we see:

What is Mozilla's intent by the phrase "must be reported if they pose
ongoing risk to the overall integrity and security of CA operations."

More specifically:

1. *"Disclosed" to whom? Public? Just Mozilla?*
2. *What does "if they pose an ongoing risk" mean? If its a one-off
attack, does that mean it does not need to be disclosed?*

More broadly, how does this wiki work when read in conjunction with the Mozilla
Root Store Policy

Specifically, section 2.4:

*Is a security incident like the one I posted above considered an instance
of a CA "failing to comply"?*

In 2.4.1 we see:

> Additionally, and not in lieu of the requirement to publicly report
incidents as outlined above, a CA Operator MUST disclose a serious
vulnerability or security incident in Bugzilla
as a secure bug

in accordance with guidance found on the Vulnerability Disclosure wiki page
.

>From my reading here, this means that all security vulnerabilities are
being disclosed privately to Mozilla. I guess this *kind of* makes sense
here.

*Would Mozilla be open to having a limited cooling-off period where these
secure bugs stay private, but after that period the information becomes
public*?

My justification for asking this is:

- Other CAs can and should learn from how a CA responded to a security
incident.
- There may be commonalities in attack patterns that these incidents
being public can help surface.
- It reassures the community that these incidents are being taken
seriously by allowing third parties to also verify and validate the
incident response and mitigation items.

Beyond this, *I'd also be interested in hearing if Chunghwa Telecom has
disclosed the impact of this recent attack on their systems (if any) to
Mozilla and the other root programs.*

--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b9fa92df-2d48-4740-988c-a147285e181dn%40mozilla.org.

Re: Vulnurability Disclosure - How does it happen?

Re: Vulnurability Disclosure - How does it happen?

Re: Vulnurability Disclosure - How does it happen?

Re: Vulnurability Disclosure - How does it happen?

Re: Vulnurability Disclosure - How does it happen?

Re: Vulnurability Disclosure - How does it happen?

Vulnurability Disclosure - How does it happen?

7 matches

Site Navigation

Mail list logo

Footer information