Compliance Overview
Standards and other specifications that you may be required to show compliance with are usually large with many options. Many times these options are also described vaguely requiring some level of interpretation. Interpretations usually get to a point of common understanding between different stakeholders after some period of time. Adding insult to the injury is that interpretations and specifications also change over time. In addition, many standards are large and contain many parts that are irrelevant for most use cases, so implementing a standard to the letter is not cost efficient neither for the implementor nor for the user.
All this considered, compliance is not a trivial concept.
Related specifically to PKI, a very small pick of some specifications that you may be asked to be compliant with includes RFC5280, RFC4210, RFC4211, RFC7030, RFC8555, RFC6010, RFC6960, RFC3739, CA/B Forum BR 1.7.3, EV SSL Certificate Guidelines 1.7.4, EV Code Signing Guidelines v. 1.4, 3GPP 33.310, EN 319 401, EN 319 411, EN 319 412, ETSI TS 119 495, ICAO 9303, PCI-DSS, NIST SP 800-73, FIPS 201-2, FPKIPA, ETSI TS 103 097, IEEE 1609.2, just to name a few.
It is safe to say that any type of compliance requires a fair amount of knowledge about a lot of details.
Implementation or Operation
A question that comes up is who manages compliance. Is it the implementor of a product or the organization operating the product delivering a service? In reality it is usually somewhere in between. Products should implement capabilities of configuring them, by the operator, to be compliant. Due to the number of standards, each requires different configurations and a configuration compliant with one specification may be non-compliant with another specification, here it is up to the operator to keep track of configuration.
Compliance over Time
Compliance with various standards is most of the time possible to demonstrate at a specific point in time, still considering that you don't fully implement many standards. But compliance is hard to keep up in the long run as specifications evolve constantly, interpretations change in various forums (some closed and some open). Just considering the sheer number of specifications to be compliant with, and the number of forums where these are handled in practice makes it impossible for the people actually implementing the standards to keep track of everything that is going on.
Compliance is continuous work, it is not a one-time effort.
Falling out of Compliance
How does it happen that an organization, being compliant once, becomes non-compliant? There are a number of reasons this can happen, including but not limited to:
Compliance specification updates
Specification re-interpretation in the governing forum
Discovery of previously non-discovered compliance details
Accidental re-configuration of the system
Deliberate re-configuration of the system to achieve one compliance, breaking another
Software bugs
As understood by now, maintaining compliance requires continuous work and tools to monitor the system and compliance, as well as to track changes and ensure it's done in a controlled and repeatable way.
Do I need Compliance?
This question has to be answered by yourself of course. There are basic things you absolutely want to be compliant with, such as RFC5280, if you want to be interoperable with various client software. There are other things that may become more of a burden, say a WebTrust or eIDAS audit if you do not have any external driving force for these. The reasons for compliance with the range of standards (a few listed above can be ranging depending on your use case:
- As wide interoperability as possible
- Industry-specific standards
- Regulations
- External or internal security requirements
- Generic trust posture (also internal or external)
You typically don't want compliance requirements that force you to do things that drive cost without making sense for your specific use case.
One Time vs Continuous Monitoring
One time, and regularly occurring, compliance monitoring plays an important role. When implementing a new system, or a new requirement, it is normal to manually verify compliance. During regular audits this is also verified. During these verifications personnel with the needed skills analyze systems and output, creating appropriate configuration, controls and processes.
During operation of the system you can deploy tools, that continuously validate the compliance achieved in the above step, ensuring that things don't start to break unexpectedly.
Any serious compliance work should involve both the regularly occurring (one time) compliance audits and continuous monitoring.
EJBCA Compliance Assisting Tools
EJBCA comes with a large set of tools that can help you manage compliance over a long time, as well as monitor for unexpected changes, keep track of changes and perform changes in a repeatable way. Using these tools, tailored for your specific needs, can help lower the risk of falling out of compliance.
These tools are numerous and it can be hard to keep track of all of them. This blog post outlines the most important ones, as of the writing date. New tools are continuously developed, and new documentation added, so be sure to check the product documentation and release notes when new versions of EJBCA are released.
Also note that different tools are more or less easily available on different platforms. For example using an Appliance or Cloud installation with limited access to the command line limit available options to run local scripts and similar.
Validation and Compliance features
This is a list of different features in EJBCA that are useful for compliance work. It is not possible to say which you should use for specific deployments and which not, as each environment is unique.
The list starts with basic configuration, and ends up with more specific tools.
Naturally this list is a snapshot in time when this blog is posted, and also does not describe all possible features in EJBCA, but a subset.
Certificate Profiles
In certificate profiles you configure the basic technical contents of certificates. It specifies the certificate contents, in detail. What type of keys they can contain, what certificate extensions (such as key usage) should be present, and what can be overridden by the caller (RA or user). This is the static content of a type of certificate.
See Certificate Profiles Overview in the EJBCA documentation.
Important compliance fields are:
End entity profiles
The end entity profile defines the dynamic, or user-specific fields, of a certificate along with some meta data.
See End Entity Profiles Overview in the EJBCA documentation.
The most important fields are the Subject DN fields. Subject DN fields define, unless DN Override is allowed in the certificate profile, which subject DN fields must be present and which may be present. Other DN attributes that are not enabled in the end entity profile is not allowed.
You can also enable validation of requested DN fields, by configuring the Validation field which is present for every configured DN field. This enables regexp validation of fields, for example size and other format restrictions.
Validators
Validators are functions that can be used to validate various aspects of a request. It is possible to use both built-in validators and external scripts.
The built-in validators are:
RSA and EC Key Validators. Validates that public keys fulfill CA/B Forum Guidelines, including FIPS 186-4 and NIST (SP 800-89 and NIST SP 56A: Revision 2) requirements, and is not a ROCA (CVE-2017-15361) weak key.
Public Key Blocklist Validators: Validates that the public key not on one of the blocklists, uploaded by an administrator. Most commonly used to check that the key is not one of the old Debian weak keys.
Domain Blocklist Validator. Validates domain names to issue certificates for (as subject alternative DNSName's) against a administrator defined blocklist, i.e. domains forbidden to issue for.
CAA Validator. Validates domain names to issue certificates for (as subject alternative DNSName's) according to RFC 8659.
Google Safe Browsing Validator. Validates domain names to issue certificates for (as subject alternative DNSName's) against Google Safe Browsing database, i.e. that it is not a known phishing or malware spreading site.
In addition to the built-in validators you can also call external scripts with the External Command Certificate Validator. For example using a tool such as Zlint to check the certificate against CA/B Forum requirements, or the eIDAS Inspector to check against eIDAS requirements.
Validation can be performed in various stages of issuance, before or after the actual certificate has been created and signed. Check the documentation for the details.
Audit logging
Of course you can not talk about compliance without mentioning audit logging. Audit logs can be produced on file, shipped to syslog, and stored in the database. Audit logging is there to give a trace of every security related event in the PKI system. This is not the same as everything that happens, and an audit log is separate from a complete event log. For example, events that cause a change (such as issuing a certificate or editing a profile) are audit logged, while events that do not change anything (such as reading revocation status to send an OCSP response) are not logged because nothing was changed. At the same time, non-changing events such as granting access, or receiving a certificate request are also logged. It's not black and white, but it is documented.
For the compliance and monitoring topic you will always be able to see in the audit log if a profile was changed. You will be able to see who, when and what changed. You can of course have triggers in your monitoring system on these events so no profile changes can happen undetected.
Validation/Conformance tool
In addition to other validation tools, there is also a separate Validation/Conformance tool shipped with EJBCA. The special feature about this tool is that it is a standalone tool that compares issued certificates (and OCSP responses) to a template that you create. Once you have a certificate the looks exactly the way you want it, you can compare the issued certificate with that to get an alarm if they suddenly stop matching. This is useful to detect configuration changes that cause some unexpected change to the output.
It can also validate only a sampling, say every 100th, issued certificate or OCSP response, making it suitable for high performance deployments where you can't afford the validation latency in every certificate.
ConfigDump
A tool designed to make repeatable installation and configuration simple is ConfigDump. ConfigDump enables you to export configuration, of almost everything, as human-readable, and machine parsable YAML. You can use the exported YAML files for multiple purposes, including but not limited to:
Creating and testing profiles and other configuration on a test system before moving it to production, where it can be imported.
Version control of configuration, tracking configuration in a VCS such as Git.
Configuration monitoring, exporting configuration nightly and comparing it to a defined version in the VCS.
These are just some possible usages of ConfigDump, making it a great tool for compliance configuration and monitoring.
Configuration checker
For Administrators using the CA UI of EJBCA the experimental Configuration Checker, gives an immediate overview and warnings about some common misconfigurations that we have noticed out there.
Publishers
Publishers, while being used for the Validation/Conformance tool, can also be used for any custom validation that you may imagine, including sending certificates to your personal archive, an S3 bucket, or similar ideas.
About EJBCA
EJBCA Enterprise, EJBCA Software and Hardware Appliance, EJBCA Cloud and EJBCA SaaS are developed by PrimeKey.
PrimeKey® and EJBCA® are trademarks of PrimeKey Solutions AB.
Posts
No comments:
Post a Comment