Re: Symantec Response T
On Tue, Apr 11, 2017 at 12:42 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In various rounds of questioning at the time we were focussing purely on > this incident, I asked Symantec what processes they had in place for > checking that the RAs were doing what they should. Their answer was > "WebTrust audits". So I believe they have already said that no such > examination was done. I'm sure they'd be happy to clarify, though. > In attempting to make an objective evaluation of the trustworthiness of Symantec, in either its past operations or as a future predictor, we essentially need to understand 1) That Symantec understood the gravity of the situation 2) That Symantec took it seriously and responded appropriately relative to the trust it was granted 3) That Symantec remains committed to doing so in the future, and with specific plans to identify and remedy the issues On the basis of the information provided, I see no reason to believe the answer to #1 is that they did not (or that they "disagreed"), the answer to #2 is that "They did not", and the answer to #3 is "They are not, and have no specific plans". Symantec is asserting its processes were trustworthy, but the evidence provided wholly contradicts that conclusion (in my opinion). I'm looking to develop a meaningful understanding of what Symantec did, so that it can demonstrate that what it did was reasonable and expected, or to acknowledge there were deficiencies that have a remediation plan. The current statement appears to be that the processes were appropriate and no deficiencies - despite the Baseline Requirements clearly contradicting this - and thus it seems appropriate to suggest that Symantec should not be trusted and/or have its trust meaningfully reduced to negate the impact that these deficient practices have on the ecosystem. The burden is two-fold: 1) Are the facts correct? It does not appear Symantec has disputed these, except with respect to the RA partner audits (for which it provided evidence that supports the current conclusions and refutes their disagreement)? 2) Are there plans for the future, or an approach to the past, that is meaningful to consider when evaluating the trustworthiness. At present, Symantec's not shared such, beyond the RA remediation plans, which are at conflict with the Baseline Requirements, its CP/CPS, and its Subscriber Agreements. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response T
On 11/04/17 17:18, Ryan Sleevi wrote: > 1) On the basis of the controls Symantec described, at no point was any > mention made of Symantec performing sampling audits to ensure their RA > partners complied with either the RA partner's CP/CPS or Symantec's CP/CPS. > a) Is it fair to conclude that no such examination if done? In various rounds of questioning at the time we were focussing purely on this incident, I asked Symantec what processes they had in place for checking that the RAs were doing what they should. Their answer was "WebTrust audits". So I believe they have already said that no such examination was done. I'm sure they'd be happy to clarify, though. Most of your other questions are fairly stated (if perhaps rather broad in scope - are you expecting a total dump of all their internal procedure documents?). But particularly: > d) Is it fair to conclude that Symantec's belief is that it does not have > to follow the Baseline Requirements that it disagrees with? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response T
On Mon, Apr 10, 2017 at 10:57 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Issue T: RA Program Misissuances (January 2010 - January 2017)
>
> Program Background:
>
> Symantec has operated an RA program designed to deliver a superior
> customer experience in global markets where language skills, understanding
> of local business requirements, and physical local presence are necessary.
> RA partners have supported various certificate types, including those for
> publicly trusted SSL/TLS.
>
> The RA program for publicly trusted SSL/TLS authorized appropriately
> trained personnel at select RA partners to complete all steps for
> authentication, review, and certificate issuance.
>
> In 2011, prior to ratification of the CA/Browser Forum Baseline
> Requirements, Symantec scaled back the scope of the RA program for publicly
> trusted SSL/TLS to support only those partners whose scale of business and
> investment in the future success of that business warranted the additional
> cost associated with supporting the then-new BRs. Since 2013, there have
> been only 4 RA partners still capable of processing and issuing publicly
> trusted SSL/TLS certificates: CrossCert, Certisign, Certsuperior, and
> Certisur.
>
> Symantec has had multiple controls in place to ensure these RAs'
> compliance with the BRs:
>
> Documentation:
> 1. Symantec operates an internal Knowledge Base ("KB") for its
> authentication staff and RA partners that contains detailed step-by-step
> procedures for performing each of the tasks required to validate the
> identity asserted in a certificate request.
> 2. The KB reinforces acceptable and unacceptable sources of validation
> information and processes using a subset of the information in the BRs.
> 3. The KB explains request flagging, flag reasons, and flag clearing
> procedures.
>
> Training & Exams:
> 1. Topics include BR changes, CPS changes, process changes resulting from
> industry incidents regardless of the CA involved, and a review of
> Symantec's procedures that extend the Baseline Requirements.
> 2. Exams are modified and retaken annually as criteria to renew individual
> access certificates or after significant internal or external process
> changes.
>
> Technology During Authentication:
> 1. Each request is screened for trade compliance, high-risk names,
> potential phishing (strings used in scam domains, high-profile brands), and
> other potentially risky content such as "test". Potential failures are
> flagged, preventing RA issuance, until and unless further review and
> analysis is completed.
> 2. Risk flags require manual override by authentication personnel -
> internal or RA personal as appropriate - for certificate issuance to
> proceed. Flag clearing privileges are only granted to personnel who are
> have completed the requisite training and passed appropriate exams.
>
> Technology Pre- and Post- Issuance:
> 1. Each request is screened to ensure elements outside of the subject
> information are BR compliant (e.g. SAN fields are complete, proper validity
> limits are in place, 2048 bit or higher key lengths are used, etc.). This
> scan is done after Authentication personnel approve the request and before
> it is issued. These checks cannot be overridden.
> 2. Daily, we rescan all certificates issued on the prior day using these
> same checks.
>
> Audit:
> 1. We requested independent WebTrust audit reports from RAs and assessed
> them for material findings pursuant to BR 8.4 regarding WebTrust audited
> Delegated Third Parties. See issue V addressing audits.
>
> Customer-Facing Controls:
> 1. Symantec supports Certification Authority Authorization, putting
> control of authorized CAs in the hands of customers.
> 2. Symantec logs publicly trusted certificates to Certificate Transparency
> Logs and offers a CT monitor to provide visibility for all customers to
> enable detection of suspect certificates.
>
> CrossCert Test Certificate Issue:
>
> On January 19, 2017, Andrew Ayer, an independent researcher posted the
> results of an analysis of public Certificate Transparency logs through
> which he identified roughly 270 instances of suspicious certificates issued
> by multiple CAs, including Symantec, containing the words "test" or
> "example" in the subject information.
>
> Symantec determined that 127 of these certificates were issued from
> Symantec operated CAs and that all 127 had been issued by the RA CrossCert.
> All but 31 had already expired or been revoked.
>
> Immediate Response
> Andrew Ayer's report was a certificate problem report under BR 4.9.5 which
> required us to begin an investigation within 24 hours, which we did. We
> determined that 127 certificates were in scope of the problem report.
>
> 1. On January 19, 2017, after becoming aware of this issue, Symantec
> disabled issuance privileges for all CrossCert staff.
> 2. On January 20, 2017, Symantec revoked the 31 still valid and active
> certificates. These
Symantec Response T
Issue T: RA Program Misissuances (January 2010 - January 2017)
Program Background:
Symantec has operated an RA program designed to deliver a superior customer
experience in global markets where language skills, understanding of local
business requirements, and physical local presence are necessary. RA partners
have supported various certificate types, including those for publicly trusted
SSL/TLS.
The RA program for publicly trusted SSL/TLS authorized appropriately trained
personnel at select RA partners to complete all steps for authentication,
review, and certificate issuance.
In 2011, prior to ratification of the CA/Browser Forum Baseline Requirements,
Symantec scaled back the scope of the RA program for publicly trusted SSL/TLS
to support only those partners whose scale of business and investment in the
future success of that business warranted the additional cost associated with
supporting the then-new BRs. Since 2013, there have been only 4 RA partners
still capable of processing and issuing publicly trusted SSL/TLS certificates:
CrossCert, Certisign, Certsuperior, and Certisur.
Symantec has had multiple controls in place to ensure these RAs' compliance
with the BRs:
Documentation:
1. Symantec operates an internal Knowledge Base ("KB") for its authentication
staff and RA partners that contains detailed step-by-step procedures for
performing each of the tasks required to validate the identity asserted in a
certificate request.
2. The KB reinforces acceptable and unacceptable sources of validation
information and processes using a subset of the information in the BRs.
3. The KB explains request flagging, flag reasons, and flag clearing procedures.
Training & Exams:
1. Topics include BR changes, CPS changes, process changes resulting from
industry incidents regardless of the CA involved, and a review of Symantec's
procedures that extend the Baseline Requirements.
2. Exams are modified and retaken annually as criteria to renew individual
access certificates or after significant internal or external process changes.
Technology During Authentication:
1. Each request is screened for trade compliance, high-risk names, potential
phishing (strings used in scam domains, high-profile brands), and other
potentially risky content such as "test". Potential failures are flagged,
preventing RA issuance, until and unless further review and analysis is
completed.
2. Risk flags require manual override by authentication personnel - internal or
RA personal as appropriate - for certificate issuance to proceed. Flag clearing
privileges are only granted to personnel who are have completed the requisite
training and passed appropriate exams.
Technology Pre- and Post- Issuance:
1. Each request is screened to ensure elements outside of the subject
information are BR compliant (e.g. SAN fields are complete, proper validity
limits are in place, 2048 bit or higher key lengths are used, etc.). This scan
is done after Authentication personnel approve the request and before it is
issued. These checks cannot be overridden.
2. Daily, we rescan all certificates issued on the prior day using these same
checks.
Audit:
1. We requested independent WebTrust audit reports from RAs and assessed them
for material findings pursuant to BR 8.4 regarding WebTrust audited Delegated
Third Parties. See issue V addressing audits.
Customer-Facing Controls:
1. Symantec supports Certification Authority Authorization, putting control of
authorized CAs in the hands of customers.
2. Symantec logs publicly trusted certificates to Certificate Transparency Logs
and offers a CT monitor to provide visibility for all customers to enable
detection of suspect certificates.
CrossCert Test Certificate Issue:
On January 19, 2017, Andrew Ayer, an independent researcher posted the results
of an analysis of public Certificate Transparency logs through which he
identified roughly 270 instances of suspicious certificates issued by multiple
CAs, including Symantec, containing the words "test" or "example" in the
subject information.
Symantec determined that 127 of these certificates were issued from Symantec
operated CAs and that all 127 had been issued by the RA CrossCert. All but 31
had already expired or been revoked.
Immediate Response
Andrew Ayer's report was a certificate problem report under BR 4.9.5 which
required us to begin an investigation within 24 hours, which we did. We
determined that 127 certificates were in scope of the problem report.
1. On January 19, 2017, after becoming aware of this issue, Symantec disabled
issuance privileges for all CrossCert staff.
2. On January 20, 2017, Symantec revoked the 31 still valid and active
certificates. These certificates had been issued between December 28, 2016 and
January 18, 2017.
3. Symantec promptly took over validation and issuance for all pending and new
orders submitted through CrossCert. Since then, Symantec's authentication team
has continued to
