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 certif
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 f