[cabfcert_policy] Trusted Roles Discussion
Ben Wilson
ben.wilson at digicert.com
Wed Mar 30 08:19:17 MST 2016
Maybe that is one way of segmenting it away from the trusted roles discussion – maybe by saying somewhere “Software development SHALL occur in an environment separate from the CA’s operational environment and data resources.”
From: Moudrick M. Dadashov [mailto:md at ssc.lt]
Sent: Tuesday, March 29, 2016 11:25 PM
To: Tim Hollebeek <THollebeek at trustwave.com>; Ben Wilson <ben.wilson at digicert.com>; Dean Coclin <Dean_Coclin at symantec.com>; policyreview at cabforum.org
Subject: Re: [cabfcert_policy] Trusted Roles Discussion
software development must be a separate environment, it must have its own data resources separate from CA's operational data. I know, this is not always easy..
Thanks,
M.D.
On 3/30/2016 12:26 AM, Tim Hollebeek wrote:
Software development is a huge blind spot in most security policies because they generally cater to and are written by auditors and operational folks. This isn’t the first time someone has pointed out that’s moderately insane, but yeah, I also hesitate to innovate in the area.
From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Tuesday, March 29, 2016 5:13 PM
To: Dean Coclin; policyreview at cabforum.org <mailto:policyreview at cabforum.org>
Subject: Re: [cabfcert_policy] Trusted Roles Discussion
Thanks, Dean. I agree with the comments. Especially on bullet points 3 & 7 and on the concern about language in 5.1.2.
Interestingly, I have often wondered why CA application developers have not been included in the traditional PKI trusted role definitions. I’m slightly hesitant to break new ground in this area.
Ben
From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Dean Coclin
Sent: Tuesday, March 29, 2016 3:06 PM
To: policyreview at cabforum.org <mailto:policyreview at cabforum.org>
Subject: Re: [cabfcert_policy] Trusted Roles Discussion
Here are some comments from our team:
5.1 Bullet points 3 and 7 both seem to be saying the same thing.
Bullet 3: “….. personnel having access to restricted portions of its repository.”
Bullet 7: “Access to restricted portions of the certificate repository”
5.1 – See two critical functions not represented who could definitely “introduce security problems” if their roles are not carried out properly.
1. CA Application developers and persons with access to uncompiled source code.
2. Systems operations personnel who have privileged access to the data center systems
5.1.2 Section requires CA to disclose those tasks that require the involvement of 2 or more persons. General concern with this as I could see certain browsers wanting to dictate to what level of detail CAs “disclose” their tasks. If they are ok with high level task descriptions that is fine but if they get too granular I can see it being operationally burdensome to continually make updates to the CPS when CAs change internal procedures (possibly adding or deleting tasks, depending on how they are defined.). Additionally, if the CA misses a CPS update, then the CA could end up with a finding in their audit.
From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Thursday, March 24, 2016 11:19 AM
To: Silva, Marcelo <masilva at visa.com <mailto:masilva at visa.com> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org>
Subject: Re: [cabfcert_policy] Trusted Roles Discussion
Here is a draft proposal.
5.1. PROCEDURAL CONTROLS
5.1.1. Trusted Roles
A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. Trusted role operations include:
• The validation, authentication, and handling of information in Certificate Applications
• The acceptance, rejection, or other processing of Certificate Applications, revocation requests, renewal requests, or enrollment information
• The issuance, or revocation of Certificates, including personnel having access to restricted portions of its repository
• Access to safe combinations and/or keys to security containers that contain materials supporting production services
• Access to hardware security modules (HSMs), their associated keying material, and the secret share splits of the PINs that protect access to the HSMs
• Installation, configuration, and maintenance of the CA
• Access to restricted portions of the certificate repository
• The ability to grant physical and/or logical access to the CA equipment
Each CA or Delegated Third Party SHALL:
a. Follow a documented procedure for appointing individuals to Trusted Roles and assigning responsibilities to them;
b. Document the responsibilities and tasks assigned to Trusted Roles and implement “separation of duties” for such Trusted Roles based on the security-related concerns of the functions to be performed;
c. Ensure that only personnel assigned to Trusted Roles have access to Secure Zones and High Security Zones;
d. Ensure that an individual in a Trusted Role acts only within the scope of such role when performing administrative tasks assigned to that role;
e. Require employees and contractors to observe the principle of “least privilege” when accessing, or when configuring access privileges on, Certificate Systems;
f. Require that each individual in a Trusted Role use a unique credential created by or assigned to that person in order to authenticate to Certificate Systems;
g. Grant administration access to Certificate Systems only to persons acting in Trusted Roles and require their accountability for the Certificate System’s security;
h. Change authentication keys and passwords for any privileged account or service account on a Certificate System whenever a person’s authorization to administratively access that account on the Certificate System is changed or revoked.
5.1.2. Number of Individuals Required per Task
Where multi-party control is required, all participants shall hold a Trusted Role. In the CA’s CPS, the CA or Delegated Third Party SHALL disclose those tasks that require the involvement of two or more persons, including the generation, activation, and backup of CA keys.
5.1.3. Identification and Authentication for Trusted Roles
Each CA or Delegated Third Party SHALL:
a. Require that each individual in a Trusted Role use a unique credential created by or assigned to that person in order to authenticate to Certificate Systems; and
b. Implement multi-factor authentication to each component of the Certificate System that supports multi-factor authentication.
5.1.4. Roles Requiring Separation of Duties
No stipulation.
5.2. PERSONNEL CONTROLS
5.2.1. Qualifications, Experience, and Clearance Requirements
Individuals appointed to any Trusted Role SHALL be employees, contractors, or employees of a contractor of the CA or Delegated Third Party and bound by terms of employment or contract, and have successfully completed an appropriate training program. Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA or Delegated Third Party, the CA or Delegated Third Party SHALL verify the identity, qualifications, and trustworthiness of such person. The CA SHALL set forth its verification practices in its CPS.
5.2.2. Background Check Procedures
Persons fulfilling Trusted Roles shall pass a comprehensive background check.
Prior to commencement of employment in a Trusted Role, the CA shall conduct background checks (where possible and in accordance with local law) which include the following:
• Confirmation of previous employment, if any;
• Check of professional reference;
• Confirmation of the highest or most relevant educational degree obtained;
• Search of criminal records (local, state or provincial, and national);
• Check of credit/financial records; and
• Identification verification via government-issued photo ID check.
Factors revealed in a background check that should be considered grounds for rejecting candidates for Trusted Roles or for taking action against an individual currently serving in a Trusted Role generally include (but are not limited to) the following:
• Misrepresentations made by the individual;
• Highly unfavorable or unreliable professional references;
• Certain criminal convictions; and
• Indications of a lack of financial or personal responsibility.
Background checks SHALL be refreshed at least every ten years.
5.2.3. Training Requirements and Procedures
All personnel performing duties in Trusted Roles SHALL receive comprehensive training. Training SHALL be conducted in the following areas:
• Security principles and mechanisms
• All PKI software relevant to their duties on the Certificate System
• All PKI duties they are expected to perform
• Disaster recovery and business continuity procedures
• Relevant stipulations of this policy
The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA’s Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), and these Requirements.
The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.
The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task.
The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements.
5.2.4. Retraining Frequency and Requirements
All personnel in Trusted Roles SHALL maintain skill levels consistent with the CA’s training and performance programs. Retraining SHALL take place whenever a significant change to the Certificate System, policies, or procedures occur.
Documentation shall be maintained identifying all personnel who received training and the level of training completed.
5.2.5. Job Rotation Frequency and Sequence
No stipulation.
5.2.6. Sanctions for Unauthorized Actions
Appropriate administrative and disciplinary actions as documented in organization policy shall be taken against personnel who perform unauthorized actions (i.e., not permitted by this CP or other policies) involving the CA’s systems, the certificate status verification systems, and the repository. Disciplinary actions may include measures up to and including termination and shall be commensurate with the frequency and severity of the unauthorized actions.
5.2.7. Independent Contractor Controls
Contractor personnel filling Trusted Roles SHALL be subject to all requirements stipulated in this document.
5.2.8. Documentation Supplied to Personnel
Documentation sufficient to perform duties and procedures for each Trusted Role SHALL be provided to the personnel filling that Trusted Role.
From: Silva, Marcelo [mailto:masilva at visa.com]
Sent: Thursday, March 24, 2016 9:03 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org>
Subject: RE: Trusted Roles Discussion
I agree with Ben.
Additionally I think we have always to make a clear distinction between RA and RA system, once RA can be used to identify an organization that is a Registration Authority for a CA, and RA system is the system itself managed by the RA organization.
From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Thursday, March 24, 2016 10:46 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org>
Subject: Re: [cabfcert_policy] Trusted Roles Discussion
After talking on the call about this, I think it is better if we don’t go down this path of defining specific roles. Instead, Peter suggested that we outline tasks or functions to be performed and then specify that they be performed by a person in a trusted role, and that persons in trusted roles receive training appropriate to the performance of the task or function assigned. That will make this section 5.2.1 shorter and easier to digest, and therefore the ballot will be more likely to pass.
From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Thursday, March 24, 2016 7:57 AM
To: policyreview at cabforum.org <mailto:policyreview at cabforum.org>
Subject: [cabfcert_policy] Trusted Roles Discussion
For discussion today:
European - ETSI
U.S. - NIST
CABF Proposal?
- System Administrators: Authorized to install, configure and maintain the TSP trustworthy systems for service management.
CA Administrator: Installation, configuration, and maintenance of the CA and CSS
Administrator – responsible for the installation, configuration, and maintenance of systems
- System Operators: Responsible for operating the TSP trustworthy systems on a day-to-day basis.
Authorized to perform system backup and recovery.
Operations Staff: Registering new subscribers and requesting the issuance of certificates. …
Configuring certificate profiles or templates
Operator – responsible for backup and recovery
- Security Officers: Overall responsibility for administering the implementation of the security practices.
Security Auditors are responsible for internal auditing of CAs and RAs. Security Auditors shall review, maintain, and archive audit logs, and perform or oversee internal audits (independent of formal compliance audits) to ensure that CAs and RAs are operating in accordance with the associated CPSs
Security Officer – responsible for administering the implementation of the security practices.
- System Auditors or evaluators: Authorized to view archives and audit logs of the TSP trustworthy systems.
See above
Internal auditors - -responsible for reviewing the audit logs
RA Staff - Installation, configuration, and maintenance of the RA, etc.
Validation Specialist – responsible for validating certificate requests
_____
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
_______________________________________________
Policyreview mailing list
Policyreview at cabforum.org <mailto:Policyreview at cabforum.org>
https://cabforum.org/mailman/listinfo/policyreview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160330/1ddf1096/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160330/1ddf1096/attachment-0001.bin
More information about the Policyreview
mailing list