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.
- How is version control maintained for policy templates?
We are using Verizon UniCERT PKI software so version control from the
software side is controlled intrenally in CAO
database components. Every policy (template) has its own number, status, date
of creation and modification. Every change in
this template/policy is noted in read-only audit log that policy/temaplte
with given id/name was modified and by who. Audit log is secured from tampering
and can be accessed only by person with role Auditor by using multifactor
authentication including physical access to datacenter room, dedicated domain
credentials, smartcard (PIN) with certificate to login to Auditor
application module. Every modification to policy/template enforces new version
of the policy/template with new seqential number, dates and so on. Older
version can not be deleted, only can be marked as "retired".
- 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.
- 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.
- 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.
- 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.
Best regards,
Piotr Grabowski
________________________________
Od: Wayne Thayer <wtha...@mozilla.com>
Wysłane: wtorek, 9 października 2018 23:45:39
Do: Grabowski Piotr
DW: mozilla-dev-security-policy
Temat: Re: Odp.: 46 Certificates issued with BR violations (KIR)
On Tue, Oct 9, 2018 at 5:30 AM Grabowski Piotr
<piotr.grabow...@kir.pl<mailto:piotr.grabow...@kir.pl>> wrote:
Hello Wayne,
Please find our comments below:
So far the process for modifying policy templates was controlled by only one
person at the moment. Although these persons
have an extensive experience in PKI and preparing certificate templates and in
common daily duties they work with serveral CA's and with hundreds of templates
and it was the first (and we hope the last) time that something was
misconfigured . This incident showed us that this process should be definitely
changed and that's why practicing due care we are updating remediation steps or
plan for:
1. Reviewed all certificate policy templates for ensuring that all of them are
BR comliant. /done
2. All the certificates owners were contacted and agreed on issuance new BR
compliant certificates in time convenient for them, preferably not later than
by the end of this year and revocation current ones. /done
3. Added procedural step for periodic certificate policy templates validation.
/done
4. Implement dual CAO control for modifying policy template which requires the
presence of 2 CAO's (Certification Authority Operators) /done
5. CAO audit logs will be daily scanned by system Auditor for policy change
events and comapared if they match events from point 4) /done
6. Implement pre-issuance linting - we have sent request, urgent need to our
PKI software vendor about delivery this functionality.
If we know the timeframe we will update this report.
Do you think it is a sufficient response to incident?
I do appreciate your prompt response, but #4 in particular strikes me as an
inadequate quick fix lacking any plan to make a concerted effort to learn from
this mistake.
- Is the new dual control process documented in a manner that will be auditable
by your external auditors?
- How is version control maintained for policy templates?
- Despite the review, is it possible for one malicious employee to modify a
policy template by themselves? If not, why not?
- 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?
- Why, despite the numerous misissuances documented on this list, has KIR not
even begun the process of implementing pre-issuance linting until now?
- 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.
Also, please respond to Ryan's email questioning how this happened.
- Wayne
Best Reagrds
Piotr Grabowski
________________________________
Od: Wayne Thayer <wtha...@mozilla.com<mailto:wtha...@mozilla.com>>
Wysłane: poniedziałek, 8 października 2018 19:13:46
Do: Grabowski Piotr
DW: mozilla-dev-security-policy
Temat: Re: 46 Certificates issued with BR violations (KIR)
Thank you for the incident report. I have posted it to the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497
On Mon, Oct 8, 2018 at 8:25 AM piotr.grabowski--- via dev-security-policy
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Here's the incident report:
1. How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, via a
discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
Email from Wayne Thayer Oct 1, 2018
2. A timeline of the actions your CA took in response.
A. Oct 2, 2018 - Investigation began.
B. Oct 4, 2018 - Found impacted certificate policy templates.
C Oct 4, 2018 - All the certificates owners were contacted and agreed on
issuance new BR compliant certificates in time convenient for them,
preferably not later than by the end of this year and revocation current
ones.
D. Oct 8, 2018 - Fixed impacted certificate policy templates.
E. Oct 8, 2018 - This disclosure.
Ongoing:
F. Replacement of impacted certificates
G. Training of periodic certificate policy templates validation.
3. Confirmation that your CA has stopped issuing TLS/SSL certificates with
the problem.
Confirmed.
4. A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem
were issued.
There are 46 certificates. The certificates were issued between Feb 20, 2017
and Sep 25, 2018.
5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is
logged to CT and then list the fingerprints or crt.sh IDs, either in the report
or as an attached spreadsheet, with one list per distinct
problem.
Added as attachment
https://crt.sh/?caid=15985&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
6. Explanation about how and why the mistakes were made or bugs introduced,
and how they avoided detection until now.
The the incident concerns 46 certificates in the vast majority issued on KIR
S.A. internal system purposes.
The root cause of this issue was human error in certificate policy templates.
"Human error" is not a sufficient response to this questions. Please describe
the process in place for modifying policy templates and how it failed to catch
this problem.
Remediation items:
1. Reviewed all certificate policy templates for ensuring that all of them are
BR comliant.
2. All the certificates owners were contacted and agreed on issuance new BR
compliant certificates in time convenient for them, preferably not later than
by the end of this year and revocation current ones.
3. Added procedural step for periodic certificate policy templates validation.
None of these remediation items will prevent future problems of this nature.
How will you improve your processes to prevent future misissuance?
I assume that KIR S.A. has not implemented pre-issuance linting. Why not? Is
there a plan to implement pre-issuance linting? When?
We have by the way question about error: ERROR: The 'Organization Name' field
of the subject MUST be less than 64 characters.
According to https://www.ietf.org/rfc/rfc5280.txt and the note from this RFC
'ub-organization-name INTEGER ::= 64. For UTF8String or UniversalString at
least four times the upper bound should be allowed. So what is the max length
of this field for UTF8String?
Page 113 of RFC 5280 limits the length of the field to 64 characters regardless
of the data type:
-- Naming attributes of type X520OrganizationName:
-- X520OrganizationName ::=
-- DirectoryName (SIZE (1..ub-organization-name))
--
-- Expanded to avoid parameterized type:
X520OrganizationName ::= CHOICE {
teletexString TeletexString
(SIZE (1..ub-organization-name)),
printableString PrintableString
(SIZE (1..ub-organization-name)),
universalString UniversalString
(SIZE (1..ub-organization-name)),
utf8String UTF8String
(SIZE (1..ub-organization-name)),
bmpString BMPString
(SIZE (1..ub-organization-name)) }
[logo]
Krajowa Izba Rozliczeniowa S.A., zarejestrowana w Sądzie Rejonowym dla m. st.
Warszawy,
XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000113064,
NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł
Informacja zawarta w tej korespondencji jest przeznaczona tylko dla osoby lub
jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne
informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować,
rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku
otrzymania tej korespondencji przez pomyłkę, proszę powiadomić nadawcę za
pomocą emaila zwrotnego i usunąć tę korespondencję (wraz z załącznikami) z
Państwa systemu.
The information contained in this transmission is intended only for the
individual or entity to whom it is addressed. It may contain privileged and
confidential information and if you are not an indicated recipient, you must
not copy, distribute or take any action in reliance on it. If received in
error, please notify the sender by return email and delete his transmission
(and any attachments) from your system.
[logo]
Krajowa Izba Rozliczeniowa S.A., zarejestrowana w Sądzie Rejonowym dla m. st.
Warszawy,
XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000113064,
NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł
Informacja zawarta w tej korespondencji jest przeznaczona tylko dla osoby lub
jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne
informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować,
rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku
otrzymania tej korespondencji przez pomyłkę, proszę powiadomić nadawcę za
pomocą emaila zwrotnego i usunąć tę korespondencję (wraz z załącznikami) z
Państwa systemu.
The information contained in this transmission is intended only for the
individual or entity to whom it is addressed. It may contain privileged and
confidential information and if you are not an indicated recipient, you must
not copy, distribute or take any action in reliance on it. If received in
error, please notify the sender by return email and delete his transmission
(and any attachments) from your system.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
