On Wed, Oct 10, 2018 at 4:33 PM Grabowski Piotr via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Hello Wayne, > > - Is the new dual control process documented in a manner that will be > auditable by your external auditors? > > Yes, the new dual control process is already included in the document > called instruction of the security of system Szafir (internal name of the > PKI system) and it is one of the document that is presented to > internal and external auditors. > Has this been added to your CP/CPS? If not, why not? Can you please detail the additional controls that were specified? > - Despite the review, is it possible for one malicious employee to modify > a policy template by themselves? If not, why not? > > It is impossible. CAO role is one of the most trusted role so it has to > have physical access to datacenter room, dedicated domain > credentials, smartcard (PIN) with certificate to login to CAO application > module. > This does not seem to describe why it is impossible. The description of controls here reads that it is possible for a CAO to do so, if malicious, and you merely trust the CAO to not be malicious. > - Have you conducted an overall review of your practices looking for other > areas where a human error can result in misissuance? If so, what did you > find and how are you addressing it? > > Yes, we have conducted an overall review and have not found any other > areas where a human error can result in misissuance. > Put differently: Have you completed an examination of the controls in place to ensure that any and all configuration changes that may result in a change to the operation of the CA undergoes multi-party review prior to and following implementation, to ensure consistency with the CP and CPS? Are there any operations that may modify any state within the CA software, hardware, or operating environment that does not undergo multi-party review prior and following? If so, what are those operations. If not, what are the operations that you have considered and enumerated as requiring multi-party review prior to and following the modification? > - Why, despite the numerous misissuances documented on this list, has KIR > not even begun the process of implementing pre-issuance linting until now? > > We have started process of implementing pre-issuance linting just after > your email pointing our misissuance. We have requested pre-issuance > linting functionality/patch with high priority from Verizon. > This does not answer the question. It states that you have begun the request, but it does not provide insight as to why you had not previously done so. > - Why is KIR not performing post-issuance linting? This problem had been > occurring for over a year and there are readily available tools ( > https://crt.sh) that allow anyone to identify these problems. > > We will implement post-issuance linting as well. This indicates what you will do, but does not answer why you didn't do. Part of the post-mortem process is to understand what issues may have existed, given the readily available nature of the tool and the discussions on m.d.s.p. regarding other CAs. For example, perhaps the CA did not have adequate staffing to ensure participation in m.d.s.p. Perhaps the CA team did not have adequate training to recognize the similarities and/or value in such. The expectations upon CAs will continue to increase, and the question is why did KIR S.A. not increase operational oversight in line with those increased expectations, which would have allowed better detection and prevention. It is positive to hear steps are being taken now to address it, but it's reasonable to question why steps weren't taken then, when this was a knowable and identified best practice and minimum expectation of CAs. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
