1612929 - Firmaprofesional: 2019 audit Finding #2 - 6.4 Facility, management, and operational controls

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[chemalogo]

+++ This bug was initially created as a clone of Bug #1610448 +++

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

An external eIDAS and ETSI audit

Actual results:

This finding was found

Expected results:

To get a non-qualified audit report

Comment 1

[chemalogo]

During the review of the log events it was noted that full access (read and write) to the audit logs is restricted to authorized individuals. However, the person who has been assigned the role of auditor does not have permissions on the system to review the logs, whilst a read-only access is expected for such an auditor profile.

1.- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We already were aware of this issue before the last eIDAS audit carried out in March 2019.
Due to the technical knowledge required for log review, these reviews were performed by the systems personnel themselves, accompanied by the auditor

The issue arisen due to the fact that we had not enough evidence to show that we actually worked this way.

2.- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

On 2019-05, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established in which it was defined the obligation of establishing a revocation process.

On 2019-07, Firmaprofesional arisen this issue to the steering committee, who decided to endeavour a project to collect the logs of the different tools involved in the certificates lifecycle management in a single point of revision, with the possibility to define an auditor role. This would be done within the budget of 2020.

On 2019-12, due to the fact that the previous task wouldn’t be done until 2020, the Security Responsible decided to at least create the role auditor in the main tool involved in certificates management: EJBCA EE.

On 2020-01, the audit role was created on EJBCA and delivered to the personnel involved.

3.- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

This problem does not affect the issuance of certificates.

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.

This problem does not affect the issuance of certificates.

** 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.**

This problem does not affect the issuance of certificates.

6.- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The issuance of certificates is held by at least two tools (Registration Authority software -a tool developed in Firmaprofesional-, and EJBCA EE) , on different machines and synced with our secure time source (atomic clock). Thus, there is a need to have access and understand the meaning of the various logs created: logs created by the tools, logs created by the underlying systems (OS, web server, …) and so on.

This is why Firmaprofesional decided to review the logs in the way stated at point 1. From our point of view this was not a concern. But this is one of the things that audits are useful for, to help to interpret some ambiguous requirements.

So Firmaprofesional decided to change the approach to this requirement.

7.- List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

On 2019-05, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established in which it was defined the obligation of establishing a revocation process.

On 2019-07, Firmaprofesional arisen this issue to the steering committee, who decided to endeavour a project to collect the logs of the different tools involved in the certificates lifecycle management in a single point of revision, with the possibility to define an auditor role. This would be done within the budget of 2020.

On 2019-12, due to the fact that the previous task wouldn’t be done until 2020, the Security Responsible decided to at least create the role auditor in the main tool involved in certificates management: EJBCA EE.

On 2020-01, the audit role was created on EJBCA and delivered to the personnel involved.

Additionally, during the second quarter of 2020 we expect to have deployed the new logs system.

In the meanwhile, the auditor is able to review EJBCA logs theirselves and the rest of logs with the help of a SysAdmin.

Also, we are gathering more evidence of this procedure.

Comment 2

[Ryan Sleevi]

To make sure I understand about what the state was during the non-conformity, and what the state was after the non-conformity is resolved:

Prior to resolving the non-conformity, the personnel fulfilling the 'auditor' role have no access to production machines. Instead, a variety of logs are created on those machines, and only authorized individual have access (read and write) to those machines. When performing a system audit, the 'auditor' works with a system administrator, such that the system administrator logs on and demonstrates the various log files to the 'auditor', who can then inspect and make determinations.

In resolving the non-conformity, the above is true for a number of systems. However, specifically for the CA software itself, EJBCA, a new dedicated role of 'auditor' has been created which allows that account read-only access to the logs, without the assistance of a system administrator.

Firmaprofesional plans, at some time in 2020, to implement a system allowing the 'auditor' role access to the other portions of the system logs, such as from the OS or from the RA platform.

Is that a correct understanding?

Comment 3

[chemalogo]

You are right but let me clarify the last point.

Firmaprofesional is not planning, but already executing (finalizing the design phase) the deployment of a cloud-based system of centralized management of logs, for ALL logs generated by the whole system support the certificate life-cycle management.

The tool is Elastic Stack. This tool not only centralizes the logs, but also makes correlations between the logs and allows them to be viewed graphically. The intention is also to use this tool as SIEM for security logs.

It is a centralized console to visualize all the security logs that are generated and identify errors or security attacks. From our understanding It has become a standard tool for security teams to identify and investigate security incidents.

Comment 4

[Ryan Sleevi]

Wayne: I don't have further questions.

Chema: Just to make sure, the use of a cloud provider would bring them in scope of the various security requirements, and so care must be taken if using an external cloud. If using an internal cloud, then these systems would be similarly in scope. That said, it does seem like such a system would be a meaningful improvement over your prior system, so I'm glad to hear there's progress.

Comment 5

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.