Thailand National Root Certification Authority: Thailand NRCA

Electronic Transactions Development Agency CA Maturity Model

Certification Authority (CA) Maturity Model

Version 1.0

Publication
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

Document Revision History

Date Version Description
September 2023 1.0 Initial Proposal

This document has been developed to propose a model to assess the maturity level of a Certification
Authority and may be updated from time to time as public discussion progresses.
Third party sources are quoted as appropriate. ETDA is not responsible for the content of the external
sources, including external websites, nor their continued availability, referenced in this document.
Where specific vendors or product names are given, those do not mean endorsement from ETDA, but serve
as examples only.
This document presents a proposed model and is intended for educational and information purposes only.
Neither ETDA nor any person acting on its behalf is responsible for the use that might be made of the
information contained in this document. All information contained herein is provided on an “As Is” basis
with no warranty whatsoever. NRCA/ETDA does not promise any specific result, effects, or outcome from
the use of the information herein.
This document is published under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International License1.
Copyright © Electronic Transactions Development Agency, 2023
Written by Martijn van der Heide

1
Creative Commons License: <https://creativecommons.org/licenses/by-nc-sa/4.0/>
Publication
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

Table of Contents
1 INTRODUCTION ...............................................................................................................................................................2
1.1 INTENDED AUDIENCE .............................................................................................................................................................................2
1.2 RATIONALE ...........................................................................................................................................................................................3
1.2.1 Existing maturity models ....................................................................................................................................................3
1.2.2 The SIM3 approach..............................................................................................................................................................3
1.3 DEFINING THE MATURITY MODEL .........................................................................................................................................................5
1.3.1 Basic level ..............................................................................................................................................................................5
1.3.2 Intermediate level................................................................................................................................................................5
1.3.3 Advanced level .....................................................................................................................................................................5
1.4 INTENDED USE ......................................................................................................................................................................................5
1.5 NEXT STEPS .........................................................................................................................................................................................6
1.6 ACRONYMS ...........................................................................................................................................................................................6
2 METHODOLOGY USED...................................................................................................................................................7
2.1 SOURCES..............................................................................................................................................................................................7
2.1.1 SIM3..........................................................................................................................................................................................7
2.1.2 CA/B Forum Network and Certificate System Security Requirements ...................................................................8
2.2 SCORE MAPPING ON THE MATURITY LEVELS ...........................................................................................................................................9
2.2.1 Basic level ..............................................................................................................................................................................9
2.2.2 Intermediate level............................................................................................................................................................. 10
2.2.3 Advanced level .................................................................................................................................................................. 11
2.2.4 Further score creation...................................................................................................................................................... 11
3 PROPOSED MATURITY MODEL ................................................................................................................................. 12
APPENDIX A: REFERENCES ................................................................................................................................................. 19

-1-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

1 Introduction
[For those unfamiliar with the field, a quick introduction into Public Key Infrastructure (PKI) and the specific
role of the Certification Authorities (CAs) s in it, can be found in our “Establishing a Certification Authority
(CA)” handbook2.]
CAs must be highly trusted and secure organizations, as they are at the core of the PKI the world depends
on for secure communication and transactions.
The CA/B Forum3 created and maintains a set of Baseline documents a CA should implement as a minimum,
depending on the types of certificates being issued.
To assist in the validation of the Certification Policy (CP) and Certificate Practice Statement (CPS), the
Common CA Database (CCADB)4 provides a self-assessment sheet.
Public CAs that require international recognition must be audited annually by certified WebTrust (or ETSI
equivalent) auditors. The audit scope depends on the types of certificates the CA issues: all CAs must pass
the main “WebTrust Principles and Criteria for Certification Authorities” audit, if they issue SSL/TLS or
S/MIME certificates, they are required to also be audited for these additional scopes. These additional
scopes also include specific network security and Certificate System security requirements.
Both the Baseline, Self-assessment and Audit requirements documents are listed in Appendix A for
reference.
This document proposes to create a maturity model for CAs using the SIM3 model philosophy. How we
created the proposed set of parameters is explained in chapter 2. The proposed resulting model is provided
in chapter 3.

1.1 Intended audience

This proposal is intended for organizations with a role in PKI, specifically those who are operating a public
Certification Authority, as well as organizations and individuals with an interest in standards, best practices,
and maturity models.

2 Establishing a Certification Authority (CA): https://www.first.org/resources/guides/Establishing-a-

Certification-Authority-CA.pdf
3 CA/B Forum: https://cabforum.org/

4 CCADB: https://www.ccadb.org/

-2-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

1.2 Rationale
Public CAs come in all shapes and sizes:
 They can be dedicated Root CA organizations.
 They can be dedicated external Subordinate CA organizations operating under a common Root CA.
 They can exist as a department of a larger organization, such as an Internet Service Provider that
also provides SSL/TLS certificates in their web hosting package.
In all cases, the existing Baseline, Self-assessment and Audit requirement documents are very helpful to
ensure the CA is set up in a way to be trustworthy and secure, but they don’t really measure the maturity
of the organizations, as they generally only state that specific things must exist, without taking into account
how well established they are. Was a document created just by an individual employee, or has it been
signed into policy by management, maybe even reviewed regularly?

1.2.1 Existing maturity models

There already are a number of maturity models in existence, such as the NIST Cybersecurity Framework 5,
U.S. Department of Energy’s Cybersecurity Capability Maturity Model (C2M2)6, PKI Consortium’s PKI Maturity
Model7, and various ISO standards such as ISO/IEC 270018. Those are very elaborate and complete, but
1) they only focus on security aspects, and
2) as each of them covers several hundred parameters and controls, they are complex to apply.

1.2.2 The SIM3 approach

Well-established CAs may have a dedicated Computer Security Incident Response Team (CSIRT) that is
responsible for the operational security posture of the organization, and springs into action as soon as a
threat has been identified.
The CSIRT community adopted the proven Security Incident Management Maturity Model (SIM3) model9
that is maintained by the Open CSIRT Foundation10. This model can be used to assess the maturity level
of a CSIRT team on 45 parameters across 4 quadrants.

5 NIST Cybersecurity Framework: https://www.nist.gov/cyberframework

6 Cybersecurity Capability Maturity Model (C2M2): https://www.energy.gov/ceser/cybersecurity-capability-

maturity-model-c2m2
7 PKI Maturity Model: https://pkic.org/pkimm/

8 ISO/IEC 27001: https://www.iso.org/standard/27001

9 SIM3 Model: https://opencsirt.org/csirt-maturity/sim3-and-references/

10 Open CSIRT Foundation: https://opencsirt.org/

-3-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

1) O: Organizational
The organizational (‘O’) parameters focus on aspects that together describe the foundation and
extent of the CSIRT’s activities (i.e. the mandate, setup and services of the CSIRT, and the
framework connecting all organizational aspects).
2) H: Human
The human (‘H’) parameters in the framework focus on important aspects related to the CSIRT’s
staff (this refers not only to technical staff but to all staff members). Together, these parameters
reflect how the team views its staff in relation to the work of the team and how this is organized.
3) T: Tools
The tools (‘T’) parameters refer to the tools and technologies that are used by the CSIRT to reach
its objectives and offer its services to its constituency. A ‘tool’ in this context can be a list, an excel
sheet or, in most advanced cases, an actual implementation of advanced tooling.
4) P: Processes
The processes (‘P’) parameters focus on a set of processes that should be well organized in order
for a CSIRT to perform its tasks. The word ‘process’ is meant in a generic way – it includes not only
processes in the sense of a logical set of sequential or parallel steps, but also policies, both of the
more fundamental kind as well as very basic policies. Some of the Process parameters are
connected with parameters from the other categories (Organization, Human and Tools), where the
description or list is found more in those other categories, and the P-parameters focus on the steps
that need to be taken.
Each parameter’s answer is a score of 0-4:

Score Status Indicators

0 Not available / undefined / unaware
1 Implicit Known or considered but not written down,
‘between the ears,’ ‘tribal knowledge
2 Explicit, internal Written down but not formally adopted or
reviewed
3 Explicit, formalized on authority of CSIRT head Approved or published
4 Explicit, actively assessed on authority of Subject to a control process and/or review
governance levels above the CSIRT
management on a regular basis
Table 1: SIM3 answer score definitions

-4-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

1.3 Defining the Maturity Model

The SIM3 approach suits our goal for a pragmatic approach to create a model that covers all relevant
aspects of an organization, but can be assessed in one day.
We envision 3 maturity levels in the model. This may help an organization that is assessed to see a growth
path. The levels are currently defined as:

1.3.1 Basic level

For any Public CA to reach the Basic level, it must be able to pass the main “WebTrust Principles and
Criteria for Certification Authorities” audit.

1.3.2 Intermediate level

For any Public CA to reach Intermediate level, it must be able to pass both the “WebTrust Principles and
Criteria for Certification Authorities” and “WebTrust Principles and Criteria for Certification Authorities –
Network Security” audits.
This automatically means that any Public CA that would like to issue SSL/TLS or S/MIME certificates must
operate on at least an Intermediate level.

1.3.3 Advanced level

We suggest that an advanced mature organization describes a top performing Public Root CA but has no
further description as this time.

1.4 Intended use

The Maturity Model can be used as self-assessment and peer-review methods.
While it can be used for certification purposes as well, CAs already have the WebTrust audits with WebTrust
Seals as visible proof.

-5-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

1.5 Next steps

While we are already open to any and all general suggestions, criticisms, and other feedback, we are
specifically looking at feedback to help
1) Properly define and describe the 3 maturity levels Basic, Intermediate, and Advanced (chapter 1.3);
2) Decide whether there should be requirements (audits or otherwise) in addition to the ones we
defined in chapter 2.2 for each level, and
3) Validate the proposed minimum scores for each maturity level.

1.6 Acronyms
This document uses the following acronyms:

Acronym Term
CA Certification Authority, or Certificate Authority
CP Certification Policy
CPS Certificate Practice Statement
CSIRT Computer Security Incident Response Team
PKI Public Key Infrastructure
SIM3 Security Incident Management Maturity Model
Table 2: List of acronyms

-6-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

2 Methodology used
As explained in the Rationale chapter, we are aiming to create a CA Maturity Model based on the philosophy
as set forth in the SIM3 model.

2.1 Sources
CA organizations are not dedicated CSIRT organizations (they may have a CSIRT team, of course), but they
should be highly trusted and secure. There is therefore significant overlap, and many of the requirements
are the same, while additional requirements exist that are audited as well. We chose to use the CA/B Forum
Network and Certificate System Security Requirements as secondary source to create the resulting list of
parameters.

2.1.1 SIM3
SIM3 contains 45 parameters across 4 quadrants (Organization, Hunan, Tools, and Processes).
The official published standard is v1, last updated in 201911. Development is currently in progress for v2, so
we decided to use the online SIM3 Self-assessment Tool12 as it uses a v2 interim version.
We selected 26 of the 45 parameters as always useful to assess a CA organization. The parameter
descriptions have been slightly modified to suit a CA rather than a CSIRT.

Nr. Parameter SIM3 origin Name

1 CA-O-1 O-11 Security Policy
2 CA-O-5 O-8 Incident Classification
3 CA-H-1 H-1 Code of Conduct/Practice/Ethics
4 CA-H-2 H-2 Staff Resilience
5 CA-H-3 H-3 Skillset Description
6 CA-H-4 H-4 Staff Development
7 CA-H-5 H-5 Technical Training
8 CA-H-6 H-6 Soft Skills Training
9 CA-H-7 H-7 External Networking
10 CA-T-1 T-1 IT Assets and Configurations
11 CA-T-2 T-8 Incident Prevention Toolset
12 CA-T-3 T-9 Incident Detection Toolset
13 CA-T-4 T-10 Incident Resolution Toolset
14 CA-P-1 P-1 Escalation to Governance Level

11 SIM3 Framework: https://opencsirt.org/wp-content/uploads/2019/12/SIM3-mkXVIIIc.pdf

12 SIM3 Self-assessment Tool: https://sim3-check.opencsirt.org/
-7-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

15 CA-P-2 P-2 Escalation to Press Function

16 CA-P-3 P-3 Escalation to Legal Function
17 CA-P-4 P-4 Incident Prevention Process
18 CA-P-5 P-5 Incident Detection Process
19 CA-P-6 P-6 Incident Resolution Process
20 CA-P-7 P-7 Specific Incident Processes
21 CA-P-8 P-8 Audit & Feedback Process
22 CA-P-9 P-9 Emergency Reachability Process
23 CA-P-10 P-10 Best Practice Internet Presence
24 CA-P-11 P-11 Secure Information Handling Process
25 CA-P-19 P-13 Outreach Process
26 CA-P-20 P-17 Peer Collaboration Process
Table 3: Parameters with a SIM3 origin

2.1.2 CA/B Forum Network and Certificate System Security Requirements

To complement the reduced set of parameters of SIM3, we looked at the CA/B Forum Network and
Certificate System Security Requirements (NCSSR) v1.7 baseline document as secondary source.
From the document, a set of 11 common themes has been selected, which have then been converted
into SIM3-like parameters and placed in the 4 quadrants. Some of those are very specific (such as an
Infrastructure Security Architecture or Trusted Roles), while others are more generic but have a focus in the
audits (such as Change Management and Vulnerability Management).

Nr. Parameter Name

1 CA-O-2 Infrastructure security architecture
2 CA-O-3 Change management policy
3 CA-O-4 Vulnerability management policy
4 CA-T-5 Log review and alerting automation
5 CA-P-12 Trusted Roles process
6 CA-P-13 Access controls process
7 CA-P-14 System accounts process
8 CA-P-15 Offboarding process
9 CA-P-16 Change management process
10 CA-P-17 Vulnerability management process
11 CA-P-18 Penetration testing process
Table 4: Parameters with an NCSSR origin

-8-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

2.2 Score mapping on the maturity levels

To find the scores for the Basic and Intermediate maturity levels, we decided on minimum audit
requirements for each level.
The following mapping was then used:
"must exist"  2
"a formal policy/process"  3
must be comprehensive and reviewed regularly  4

2.2.1 Basic level

A basic level mature organization must be able to pass
1) the main “WebTrust Principles and Criteria for Certification Authorities” v2.2.2 audit.

Parameter Score WebTrust section

CA-O-1 3 3.1.1 - 3.1.4
CA-O-2 3 3.6.9 - 3.6.17
CA-O-3 3 3.5.2
CA-O-4 3 3.1.5, 3.1.6
CA-O-5 2 3.5.9
CA-H-3 2 3.3.1, 3.3.2
CA-T-1 2 3.2.1, 3.2.2, 3.4.16
CA-T-2 2 3.5.8
CA-T-3 2 3.5.8
CA-T-4 2 3.5.9
CA-T-5 3 3.10.1 - 3.10.18
CA-P-1 3 3.5.9
CA-P-4 2 3.5.8
CA-P-5 2 3.5.8, 3.9.13
CA-P-6 3 3.5.9, 3.5.13
CA-P-7 3 4.7.1 – 4.7.6
CA-P-8 4 3.9.8 - 3.9.12
CA-P-12 3 3.3.3, 3.3.5
CA-P-13 3 3.3.5, 3.4.23, 3.6.1 – 3.6.29
CA-P-14 2 3.6.5
CA-P-15 3 3.3.11, 3.6.2
CA-P-16 3 3.5.2, 3.5.4, 3.5.7, 3.7.1 – 3.7.9
Table 5: Basic scores from WebTrust

-9-
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

2.2.2 Intermediate level

An intermediate mature organization must be able to pass both
1) the “WebTrust Principles and Criteria for Certification Authorities” v2.2.2, and
2) the “WebTrust Principles and Criteria for Certification Authorities – Network Security” v1.7 audits.
Note: The Network Security audit scope used to be part of the SSL Baseline audit but has been separated
as the new S/MIME audit has this same set of audit requirements.
An Intermediate mature organization must also adhere to
3) the Baseline requirements as set forth by the “CA/Browser Forum Baseline Requirements Certificate
Policy for the Issuance and Management of Publicly-Trusted Certificates (SSL/TLS Server
Certificates)” v2.0.1 document
Those Baseline requirements must be addressed in the organization’s Certification Policy (CP) and Certificate
Practice Statement (CPS).

Parameter Score WebTrust section CA/B Forum SSL section

CA-O-2 4 1.1 – 1.7
CA-O-3 3 1.8
CA-O-4 3 4.2 5.4.8
CA-H-4 3 5.3.3 – 5.3.4
CA-H-5 3 5.3.3 – 5.3.4
CA-T-2 3 3.1 – 3.7, 4.1
CA-T-3 3 3.1 – 3.7, 4.1
CA-T-4 3 3.1 – 3.7, 4.1
CA-T-5 3 5.4.1
CA-P-6 3 4.9.5, 5.7.1
CA-P-7 3 5.7.1
CA-P-8 4 8
CA-P-9 3 4.9.3
CA-P-12 4 1.9, 2.1 – 2.4 5.2.2
CA-P-13 3 1.10, 2.5 – 2.9, 2.11-2.15
CA-P-14 3 2.10
CA-P-15 3 1.11
CA-P-17 3 1.12, 4.2, 4.6
CA-P-18 3 4.3 – 4.5
CA-P-19 3 4.9.3
Table 6: Intermediate scores from WebTrust and CA/B Forum

- 10 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

2.2.3 Advanced level

No specific additional audit requirements have been defined for this level, so no scores are available as a
starting point.

2.2.4 Further score creation

After this initial score selection, the remaining scores were created manually, while paying attention to the
minimum scores per parameter listed in the SIM3 Self-assessment Tool – specifically, the required scores
to become a FIRST member13 and the scores proposed by ENISA for Basic/Intermediate/Advanced National
CSIRT teams14.

13 FIRST scores source: https://www.first.org/membership/process#annex-3

14 ENISA scores source: https://www.enisa.europa.eu/publications/enisa-csirt-maturity-framework
- 11 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

3 Proposed Maturity Model

We propose the following 37 parameters and minimum scores per level.
The color scheme used for the table is:

SIM3 as the parameter source (chapter 2.1.1)

NCSSR as the parameter source (chapter 2.1.2)
Basic level minimum score derived from WebTrust (chapter 2.2.1)
Intermediate level minimum score derived from WebTrust and CA/B Forum (chapter 2.2.2)

Baseline
requirements

Intermediate
Advanced
Basic
Param Name Description
Organization
Though often information security and business continuity are treated
separately, it is more logical in the context of IT/cyber to have business
continuity as an integral part of a good security policy, and that is the
approach we take here. So, when we say 'security policy' this includes such
important aspects as 'availability', and how to get back to normal after
CA-O-1 Security Policy 3 4 4
disruptions - but the landscape is even broader than that, thought also needs
to be given to site security and resilience, and workspace security and
resilience.
Does your organization have a security policy, or set of security policies
(including BCM aspects)?
An infrastructure security architecture defines and describes the segmentation
of the network into different zones based on their functional or logical
relationship, with a specific Secure Zone for the CA platform. Production and
office networks should be strictly separated. Each network boundary must be
enforced (firewall, switch, router, gateway, or other network control device or
CA-O-2 Infrastructure security architecture 3 4 4
system) with rules that support only the services, protocols, ports, and
communications that the CA has identified as necessary to its operations.
Internet-facing systems, such as the CRL and OCSP Responders, may need
additional protection against tampering (e.g., DDoS attacks.)
Does your organization have an infrastructure security architecture?
Change management is the process of planning, implementing, and solidifying
changes in an organization and encompasses all different types, whether
CA-O-3 Change management policy those are changes in policies, procedures, configurations, and hardware or 3 3 4
software products.
Does your organization have a change management policy?
Vulnerability management is a continuous risk-based process that aims to
CA-O-4 Vulnerability management policy identify vulnerabilities and other potential weaknesses in the infrastructure, 3 3 4
followed by evaluating, prioritizing, treating, and reporting. Any remaining

- 12 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

vulnerability should be added to the organization's risk register and re-

evaluated regularly.
Does your organization have a vulnerability management policy?
An incident classification scheme usually contains at least a list of technical
incident categories to associate an incident or threat with, like whether it has
the characteristics of 'spam' or 'root compromise' or 'DDoS' etc. A popular
classification scheme of that type is ENISA's 'Reference Incident Classification
Taxonomy'.
CA-O-5 Incident Classification 2 3 3
It is however recommended to also include in such a classification some
measure of the potential severity (impact) of an incident or threat - and
potentially also its assessed priority (as a high impact threat for instance can
be low priority when its probability of happening any time soon is very low).
Does your organization use some kind of incident classification?

Human
Does your organization provide guidance, guidelines or sets of rules for its
staff on how to behave professionally, in an ethical manner? Often called a
'Code of Conduct (CoC)' a 'Code of Practice (CoP)' or 'Ethics guideline', it can
provide golden rules on confidentiality, trustworthiness, and other key human
qualities expected from staff. Note that in most cases the CA's host
organization will have some kind of ethics code, but such codes are of a
generic nature and have nothing to do with the specific work that the CA
does - therefore such generic codes are not valid to satisfy this parameter
CA-H-1 Code of Conduct/Practice/Ethics The CA regularly deals with highly sensitive data, and communicates not just 2 3 3
inside the host organization, but also outside. Also, responsible behavior of
CA staff is not limited to the work context, but also relevant in private circles
where security is concerned. The Trusted Introducer CSIRT Code of Practice
(TI CCoP) can be used as CoP baseline, which was written specifically for
CSIRTs; another excellent starting point is 'EthicsFIRST' made by FIRST, which
has its own website. Do note that proper alignment with the security policy is
always necessary.
Does your organization support such a code of conduct/practice/ethics?
Does your CA have enough staffing to deal with planned or unexpected staff
members' unavailability? Such cases include illness, holidays, quitting of job ...
CA-H-2 Staff Resilience Note that staff resilience is also an aspect of Business Continuity Management 2 3 4
(BCM).
What about the staff resilience of your organization?
Does your organization have a description of the skills needed for all
employee positions related to the CA roles? All positions must be defined,
and include a description of expected staff’s skills: this includes technical,
CA-H-3 Skillset Description 2 2 3
knowledge, experience, and soft skills - e.g., communication, team spirit,
working under stress, etcetera.
Has your organization described the skillsets needed?
Does your organization have a policy for the professional development of
their staff? This parameter is about staff development as a whole, probably
including but not limited to a training plan for new staff members, personal
development planning and a catalogue of trainings for existing staff members,
team building/education schemes, and etcetera.
CA-H-4 Staff Development 2 3 4
Staff development can take the shape of on-the-job-coaching, internal or
external trainings, but also includes peer mentoring schemes (colleagues
helping each other to get better at their jobs), management evaluation
interviews, and team meetings and internal workshops.
Does your organization have such a staff development policy?

- 13 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

Does your organization provide staff members with a programme of (external

and/or internal) trainings they can take in order to improve their technical
CA-H-5 Technical Training skills, in order to meet the technically oriented targets asked for in the skillset 2 3 3
that applies to their job position.
Does your organization have such a technical training programme?
Does your organization provide staff with a programme of (external and
internal) trainings they can take in order to improve their 'soft' skills (as
opposed to the 'hard' skills). All staff should be trained in such soft skills as
team building, time management, working under stress, but especially also in
(human) communication and presentation: The latter in order to better
interact with clients, colleagues, managers, peers, local or foreign authorities,
and sometimes also the press. This applies to all sorts of media - e.g., phone,
chat, email, social media ... - and all types of communications - e.g., direct
CA-H-6 Soft Skills Training 1 2 3
talks, meetings, presentations, advisory or report writing, blog posts, tweets,
and text messages. It applies to formal and informal communications, and
not only to work activities, but sometimes also outside work (in compliance
with the ethics code). Also there needs to be attention for the fact that
although 'normal' communication may cover 90% or more of all situations,
crisis communication is different but equally important. Finally, those who
may talk to the press need additional training for that.
Does your organization have such a soft skills training programme?
Does your organization have a policy to send staff to CA-related or
cybersecurity-related meetings? This contributes to the national, sectorial,
regional and/or worldwide PKI collaboration- and those collaborations are
CA-H-7 External Networking essential for the success and effectiveness of the PKI community as a whole. 1 2 3
Also, meeting in person creates the foundation for trust relationships with
peers, and 'trust' is the cement of the PKI collaborations.
Does your organization have such a policy for external networking?

Tools
The availability of an up-to-date and sufficiently detailed list of what kind of
computer/networking/OT resources the organization uses is very important for
efficient security incident management. Such a list should include information
about hardware, software, and OT. This should include relevant
configurations: such more detailed information (including software versions in
CA-T-1 IT Assets and Configurations 2 3 3
use) is necessary to deal with threats more effectively. Some organizations
use IT assets management (ITAM) for this purpose, and maintain a
configuration management database (CMDB).
Does your organization maintain an overview of all IT assets and
configurations?
This is about having a well-defined and implemented set of tools that help
with incident prevention. These tools are part of the first line of defense for
the organization.
CA-T-2 Incident Prevention Toolset 2 3 3
Examples of prevention tools: intrusion prevention systems, antivirus
software, spam filters or vulnerability scanners.
Does your organization have a well-defined incident detection toolset?
This is about having a well-defined and implemented set of tools that help
with incident detection. These tools are like the ears and eyes of the
CA-T-3 Incident Detection Toolset organization- they bring information about threats and incidents, from 2 3 3
potential to exploited.
Does your organization have a well-defined incident detection toolset?

CA-T-4 Incident Resolution Toolset This is about having a well-defined and implemented set of tools that help 2 3 3
with incident resolution: the stage where a detected incident is being

- 14 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

addressed.
Does your organization have a well-defined incident resolution toolset?
All system activity logs created by the CA platform must be reviewed
regularly, as well as the integrity of the log files themselves. Critical events
CA-T-5 Log review and alerting automation should be alerted to (multiple) qualified staff for immediate review in an 3 3 3
automated way.
Does your organization have an automated log review and alerting method?

Processes
Each organization must be able to escalate critical incidents to the
appropriate management levels, including the highest level of governance
(e.g., board of directors, regulator, or minister) in case of potential crises or
incidents that are at least a significant threat to the reputation of the
organization.
Such escalations triggered by security incidents or other events should be
CA-P-1 Escalation to Governance Level 3 4 4
defined in accordance with the Incident Classification, which allows logically
basing the escalation on e.g., impact and priority. It is critical that the means
to escalate must be available at all times - even though the feedback or
reaction will not always be as immediate, as this is defined by higher
governance levels in the organization.
Can your organization escalate in the way meant here?
Handling the press and public media is required. In case most or all CA staff
have been tasked to not talk with the press themselves, press requests in
regard security incidents must still be handled effectively, wherever they
come in. Therefore, the staff must be able to reach out to appropriate
spokespersons who normally handle press inquiries. To avoid
miscommunication and delays that might impact on the organization’s
reputation, the staff need to be able to reach such press contacts directly
CA-P-2 Escalation to Press Function and also outside business hours, in order to give them the necessary 1 2 3
situational awareness. It is advisable that the organization itself designates a
limited amount of staff members to also be able to talk with the press, e.g.,
together with an official spokesperson - as such designated staff members will
be able to give more insight into the technical aspects of a given situation;
when such a choice is made it's advisable to give such staff members a
suitable training.
Can your organization escalate in the way meant here?
Handling legal issues including requests from law enforcement is required.
Such requests to the organization must be handled very effectively in order
to avoid that evidence is destroyed or no longer available, e.g., as a result of
automated processes removing data routinely - but also, because handling
such issues wrongly could lead to reputation damage and financial losses.
CA-P-3 Escalation to Legal Function The organization must therefore be able to reach out directly and also 2 3 3
outside business hours, to legal experts in their organization (e.g. lawyers) to
inform them about relevant issues, including but not limited to incoming law
enforcement requests or orders. The legal experts can then either handle
these issues themselves directly, or in consultation with the staff.
Can your organization escalate in the way meant here?
From a risk management perspective, incidents must be avoided, therefore
the organization should support appropriate prevention processes internally.
Examples of processes that prevent incidents from happening are: the
CA-P-4 Incident Prevention Process creation and dissemination of advisories about new security vulnerabilities; 2 3 4
port scan activities; the spreading of threat intel; the sharing of lessons learnt
from the analysis of incidents. Usually, tools are used to support these
processes, and then how to do that will be part of the process.

- 15 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

Does your organization have a process for incident prevention?

Without detecting incidents no organization is able to respond to those.
Some organizations operate their own detection capabilities (IDS, firewall logs,
CA-P-5 Incident Detection Process honeypots, ...). Others depend on receiving incident reports or utilize a SOC 3 3 4
to receive potential incidents that need to be analyzed.
Does your organization have a process for incident detection?
Any CA needs to develop at least a generic process about how to resolve,
handle, and mitigate incidents. Because it is generic, each input is processed
by the very same process in more or less the same way, although most
certainly the results will vary. Instead of focusing on the specifics of an
incident (e.g., a malware APT is very different from a DDoS attack), this
CA-P-6 Incident Resolution Process 3 3 4
process focuses on the overall step-by-step approach after the detection
process. The main steps in the process are analysis, response actions leading
to mitigation, closing and lessons learnt. Following this generic process
ensures that all incidents are handled according to the established practice.
Does your organization have a process for incident resolution?
It is very important to have a common process to handle all incidents. But
such a generic process ensures the overall workflow and cannot be tailored
for specific types of incidents, and thus will more than likely miss out on
some relevant technical aspects. An incident caused by a new malware APT
is very different from a DDoS attack blocking the Internet for an important
service. Not only are the priorities different, but also the technical response.
Therefore, it is recommended for mature organizations to identify those
incident types that are causing most of the work - and then to write specific
CA-P-7 Specific Incident Processes incident processes for those. This will allow to leave out some steps or 3 3 4
activities, while describing others in more detail or adding new ones (could be
sub-steps of the generic process). Additionally, specific incident processes can
be written not just for very common incident types, but also for mission
critical incidents (high impact, high priority), or for incidents that require a
response requiring expertise not commonly present inside the organization
itself, like legal expertise.
Has your organization described specific incident processes, beyond the
generic incident resolution process?
All CAs need quality assurance for all critical and sensitive aspects of their
operation. While various means exist to help ensure the quality levels (e.g.,
self-assessment, walk-throughs, peer reviews, internal as well as external
audits), the level of scrutiny must be defined, scoped, and maintained. Also,
it needs to be ensured that there is not just an 'audit' but also subsequent
feedback to the organization, to enable learning and improvement. We call
CA-P-8 Audit & Feedback Process 4 4 4
this the audit & feedback process. This process needs to ensure that the
appropriate quality levels are met, and that problems are recognized as soon
as possible. Unbiased, neutral feedback is mandatory as not to focus on
mistakes or errors, but instead to focus on improvement and progress, with
the mission of the organization in mind.
Has such an audit & feedback process been defined for your organization?
Each CA supports a number of communication mechanisms that can be used
to send information or incident reports to. In most cases, service windows
coincide with standard business hours. Some organizations are on call outside
such times, in accordance with their own service levels. However,
CA-P-9 Emergency Reachability Process crisis/emergency situations can and will occur, and may well require the 2 3 3
reachability of the organization even outside the normal service windows. To
allow external parties to contact the organization in such special cases, there
needs to be an emergency reachability process that describes telephone
numbers, e-mail addresses and possibly also special keywords reserved for

- 16 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

such true emergencies. The process should sanction misuse as reacting

outside the normal service windows is usually expensive. On the other hand -
given how important it potentially is - the process must be executed from
time to time to train all parties involved.
Does your organization have such an emergency reachability process?
Good communication is at the heart of the work and success of any CA and
being able to reach out over the Internet and be easily reachable are both
essential. Besides having available various communication tools, all CAs need
a process that specifies which Internet media are used in what way, in order
to monitor for incoming requests, share information, etcetera, in order to
successfully deliver their various services, and fulfil their mandate and
responsibility. The process needs to take into account, for the 3 areas
mentioned: (1) tracking by the CA of at least the standard e-mail address
security@... - and strongly recommended to take the RFC2142 standard into
account and ensure that the relevant mailbox names (postmaster and
CA-P-10 Best Practice Internet Presence webmaster deserve special attention) are tracked. And, that whoever tracks 0 2 3
those mailbox names, knows about the CA and how to pass on information
to them. (2) a web policy that ensures that all relevant information about the
CA is up-to-date and available. Additionally, it is recommended to consider
implementing a slash-security page (example: www.org.tld/security), which
can offer a wider range of security related information in regard to your (host)
organization. (3) A policy for what social media the organization tracks and
uses, and how they are to be used. Examples are Twitter, LinkedIn, and
Facebook.
Does your organization have a process that shapes its Internet presence
according to the above best practices?
Each CA receives and processes information that was labeled confidential by
those sending it in - for instance to avoid that the information falls into the
hands of attackers or becomes available on the Internet publicly before
appropriate warnings have been distributed. Therefore, external parties, but
also e.g., vulnerability researchers, are hesitant to share information unless it
can be done securely. Now apart from communication security as offered by
TLS or security applications like GPG/PGP, the information must also be
protected by the receiving organizations (secure storage, backups, etc.) - and
CA-P-11 Secure Information Handling Process 2 3 3
this must be done in compliance with relevant legislation, including privacy
laws like GDPR. To communicate the restrictions on further distribution of
sent information, the TLP (Traffic Light Protocol: see www.first.org/tlp))
protocol has been developed - and any organization is strongly advised to
use and adhere to TLP - as a minimum an organization must be able to deal
appropriately with TLP labeled information.
Does your organization have a process on how to handle information
securely?
A documented process must be followed for appointing individuals to
Trusted Roles and assigning responsibilities to them. The responsibilities and
tasks assigned to Trusted Roles must be documented and “separation of
CA-P-12 Trusted Roles process 3 4 4
duties” must be implemented for such Trusted Roles based on the security-
related concerns of the functions to be performed.
Does your organization have a Trusted Roles process?
System access to the CA platform must be granted based on the principle of
least privilege, only allowing to perform the functions required for the role,
CA-P-13 Access controls process and only Trusted Roles be allowed such access. Multi-Factor Authentication 3 3 4
should be implemented for each component of the CA platform that
supports it and authentication keys and passwords for any privileged account
or service account on the CA platform should be changed whenever a

- 17 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

person’s authorization to administratively access that account on the CA

platform is changed or revoked.
Does your organization have such an access controls process?
All system accounts should be reviewed regularly and any accounts that are
no longer necessary for operations should be deactivated.
CA-P-14 System accounts process 2 3 3
Does your organization have a process to regularly review all system
accounts?
Offboarding is a process that is run upon termination of any individual’s
employment or contracting relationship with the CA or Delegated Third Party.
The process involves returning (and possibly wiping) all company equipment
CA-P-15 Offboarding process 3 3 3
such as access cards, laptops, tablets, and media such as USB sticks, as well
as disabling all system and network accounts as soon as possible.
Does your organization have an offboarding process?
All changes should be thoroughly tested before deployment (in separate
development, test, and production environments), with a clear review and
CA-P-16 Change management process 3 3 3
approval stage, and documented afterward.
Does your organization have a change management process?
Vulnerabilities can be identified through software and hardware vendor
reports, security researcher reports, log analysis, penetration testing and other
self-assessments. After identification, the next steps involve finding possible
CA-P-17 Vulnerability management process 2 3 3
solutions, implementing, and documenting those through the regular change
management process.
Does your organization have a vulnerability management process?
Penetration testing, or Red Teaming, is an ad-hoc self-assessment process to
find vulnerabilities and other weaknesses in your infrastructure. This can be
performed by your own security team or contracted. Any identified weakness
CA-P-18 Penetration testing process 2 3 3
should be followed up through the regular vulnerability management
process.
Does your organization have a penetration testing process?
All CAs need to communicate with their Subscribers and Stakeholders, in a
variety of ways and communication methods, be it regular announcements,
CA-P-19 Outreach Process sending alerts or dealing with incidents. 2 3 4
This is a two-way process and should be described in a process.
Does your organization have such an outreach process?
It is important to be a member or part of relevant communities in order to
foster trust relationships with other teams, in order to gain better information
timely, and to improve communication, both in terms of speed and of
quality. Also, several teams will be part of a more hierarchically structured
context - for example, a Subordinate CA in a commercial organization may
need to report into a coordinating Root CA on the corporate level - or lower-
CA-P-20 Peer Collaboration Process 0 2 3
level government teams may need to report into a regulator. In all cases
such 'peer' relationships need to be defined and appropriate processes need
to be defined on both sides. If there is a hierarchical structure, the
consequences of this need to be clearly documented.
Has your organization defined what their various 'peers' are, and what the
process(es) towards those peers is/are?

- 18 -
 Thailand National Root Certification Authority: Thailand NRCA
Electronic Transactions Development Agency CA Maturity Model

Appendix A: References
Publisher Document
CA Baseline Documents
CA/B Forum CA/Browser Forum Network and Certificate System Security Requirements Link
CA/B Forum CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Link
Management of Publicly-Trusted Certificates (SSL/TLS Server Certificates)
CA/B Forum CA/Browser Forum Baseline Requirements for the Issuance and Management of Link
Publicly-Trusted S/MIME Certificates
CA Self-assessments
CCADB CCADB Self Assessment Link
CA Audit documents
CPA Canada WebTrust Principles and Criteria for Certification Authorities Link
CPA Canada WebTrust Principles and Criteria for Certification Authorities – Network Security Link
CPA Canada WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Link
Network Security
CPA Canada WebTrust Principles and Criteria for Certification Authorities – S/MIME Certificates Link
CSIRT Documents
Open CSIRT Security Incident Management Maturity Model (SIM3) Link
Foundation
Table 7: References

- 19 -