[cabf_netsec] Trusted Roles in WebTRust CA 2.0

[Silva, Marcelo]

As discussed in the Call, following below the WebTrust CA v2.1 content on Trusted Roles:

3.3.3-7 - On personnel Security


3.3.3


Trusted Roles, on which the security of the CA's operation is dependent, are clearly identified. Trusted roles include, at a minimum, the following responsibilities:

a) overall responsibility for administering the implementation of the CA's security practices;

b) approval of the generation, revocation and suspension of certificates;

c) installation, configuration and maintenance of the CA systems;

d) day-to-day operation of CA systems and system backup and recovery;

e) viewing and maintenance of CA system archives and audit logs;

f) cryptographic key life cycle management functions (e.g., key component custodians); and

g) CA systems development.




3.3.4


The CA's policies and procedures specify the background checks and clearance procedures required for Trusted Roles and non-trusted roles. As a minimum, verification checks on permanent staff are performed at the time of job application and periodically for those individuals undertaking Trusted Roles.


3.3.5


An individual's trusted status is approved prior to gaining access to systems/facilities or performing actions requiring trusted status.


3.3.6


CA Employees and Trusted Roles sign a confidentiality (non-disclosure) agreement as a condition of employment.


3.3.7


Contractors who perform Trusted Roles are subject to at least the same background check and personnel management procedures as employees.


It's also worth to mention that the term "Trust Roles" is used in multiple Criterions and Illustrative Controls in the document.



FYI... The below content was part of a draft document for the WebTrust CA v2.0:


Trusted Roles, Delegate Third Parties, and System Accounts


The CA maintains controls to provide reasonable assurance that:

*         A documented procedure for appointing individuals to Trusted Roles and assigning responsibilities to them is followed;

*         The responsibilities and tasks assigned to Trusted Roles are documented and "separation of duties" for such Trusted Roles based on the risk assessment of the functions to be performed is implemented;

*         Only personnel assigned to Trusted Roles have access to Secure Zones and High Security Zones;

*         Individuals in a Trusted Role acts only within the scope of such role when performing administrative tasks assigned to that role;

*         Employees and contractors observe the principle of "least privilege" when accessing, or when configuring access privileges on, Certificate Systems;

*         Trusted Role use a unique credential created by or assigned to that person for authentication to Certificate Systems;

*         Trusted Role using an username and password to authenticate shall configure accounts to include but not be limited to:

o   Passwords have at least twelve (12) characters for accounts not publicly accessible (accessible only within Secure Zones or High Security Zones);

o   Configure passwords for accounts that are accessible from outside a Secure Zone or High Security Zone to have at least eight (8) characters, be changed at least every 90 days, use a combination of at least numeric and alphabetic characters, and not be one of the user's previous four passwords; and implement account lockout for failed access attempts; OR

o   Implement a documented password management and account lockout policy that the CA has determined provide at least the same amount of protection against password guessing as the foregoing controls.

*         Trusted Roles log out of or lock workstations when no longer in use;

*         Workstations are configured with inactivity time-outs that log the user off or lock the workstation after a set time of inactivity without input from the user;

*         Review all system accounts at least every 90 days and deactivate any accounts that are no longer necessary for operations;

*         Revoke account access to Certificate Systems after no more than five (5) failed access attempts, provided that this security measure is supported by the Certificate System and does not weaken the security of this authentication control;

*         Disable all privileged access of an individual to Certificate Systems within 24 hours upon termination of the individual's employment or contracting relationship with the CA or Delegated Third Party;

*         Enforce multi-factor authentication for administrator access to Issuing Systems and Certificate Management Systems;

*         Each Delegated Third Party, shall be:

o   Required to use multi-factor authentication prior to the Delegated Third Party approving issuance of a Certificate; or

o   Be technically constrained that restrict the Delegated Third Party's ability to approve certificate issuance for a limited set of domain names; and

*         Restrict remote administration or access to an Issuing System, Certificate Management System, or Security Support System except when:

o   The remote connection originates from a device owned or controlled by the CA or Delegated Third Party and from a pre-approved external IP address,

o   The remote connection is through a temporary, non-persistent encrypted channel that is supported by multi-factor authentication, and

o   The remote connection is made to a designated intermediary device meeting the following:

?  Located within the CA's network,

?  Secured in accordance with these Requirements, and

?  Mediates the remote connection to the Issuing System.



(See Network and Certificate Systems Security Requirements Section 2)



Thanks,
Marcelo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190429/1b1e582f/attachment-0001.html>