[cabfcert_policy] Trusted Roles Discussion
Moudrick M. Dadashov
md at ssc.lt
Tue Mar 29 22:24:36 MST 2016
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] *On Behalf Of *Ben Wilson
> *Sent:* Tuesday, March 29, 2016 5:13 PM
> *To:* Dean Coclin; 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
> https://cabforum.org/mailman/listinfo/policyreview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160330/2be6d20e/attachment-0001.html
More information about the Policyreview
mailing list