Digi-Sign, The Certificate Corporation
Published on Digi-Sign, The Certificate Corporation (http://www2.digi-sign.com)

Home > Compliance and Standards : Certification Authority : Digi-Sign.com

By Digi-Sign
Created Feb 25 2008 - 13:47

Compliance and Standards : Certification Authority : Digi-Sign.com

PDF [1] The Digi-CA™ [2], subject to configuration, complies with more than 70 international standards [3] for Certificate Authority [4] software, services and design.

Digi-CA™ Compliance

PDF [1] The Digi-CA™ [2], subject to configuration by the Digi-CAST™ [5] Team, can comply with the following international standards for Certificate Authority [CA] software, services and design (see the Complete List of Standards & Compliance [3]).

  • 1999/93/EC [6]
  • FFIEC
  • HIPAA
  • ICAO
  • MRTD [7]
  • ANSI
  • Common Criteria
  • Sarbanes Oxley
  • SB 1386
  • ISO 27001
  • ACSI 33
  • EAL
  • FIPS
  • CONOPS
  • Gramm-Leach Bliley


See the Complete List of Standards & Compliance [3]

Combining the main legislation requirements, the Digi-CA™ [2] also meets the following standards:

  • ETSI 101 456
  • ETSI 002 176
  • ETSI 102 023
  • ETSI 101 861
  • CWA 14167-1
  • CWA 14172-3
  • CWA 14890
  • CWA 14169 / ISO 15408
  • CWA 14171
  • PKCS#5
  • PKCS#7-12
  • PKCS#15
  • 1999/93/EC [8]
  • IETF RFC 2527
  • IETF RFC 3647


List of Standards

PDF [1] Third-Party Certifications, Standards & Compliance

    Reference

     

    Description

         
  • 1999/93/EC [6]   EU Electronic Signatures Directive for Qualified Electronic Signatures and National Certification Service Providers issuing Qualified Certificates to the public.
  • 2003/59/EC   Revision of the community legislation on the access to the road transport market and on the admission to the occupation of road transport operator.
  • AES   Advanced Encryption Standard
  • CA/PKI   Certificate Authority/Public Key infrastructure
  • PKIX   X.509 based Public Key Infrastructure
  • DER   Distinguished Encoding Rules
  • PEM   Privacy Enhanced Mail
  • DES   Data Encryption Standard
  • DSA   Digital Signature Algorithm
  • LDAP   Lightweight Directory Access Protocol Version 3
  • MD5   Message-Digest algorithm version 5
  • SHA-1   Secure Hash Algorithm 1
  • SHA-2   Secure Hash Algorithm 2
  • MIME   Multi-purpose Internet Mail Extensions
  • S/MIME   Secure Multi-purpose Internet Mail Extensions
  • SSL   Secure Socket Layer
  • TLS   Transport Layer Security
  • UTF-8   8-bit Unicode Transformation Format
  • X.509 v3   Attribute Certificate Frameworks Version 3
  • RSA   Algorithm for public-key cryptography
  • Triple DES   Data Encryption Standard Block Cipher
  • CWA 14167   Trustworthy CA Systems Management
  • CWA 14169   Secure signature-creation devices EAL4+ [See HSM compliance below]
  • CWA 14172   Compliance to CEN Directives for CA ownership & Operation
  • CWA 14355   Secure Signature-Creation Devices
  • CWA 14365   Use of Electronic Signatures: Legal & Technical Aspects
  • CWA 14890   Application Interface for smart cards used as Secure Signature Creation Devices
  • CWA 15579   E-invoices and digital signatures
  • CWA 15580   Storage of Electronic Invoices
  • CWA 15581   Guidelines for eInvoicing Service Providers
  • CWA 15582   eInvoice Reference Model for EU VAT purposes specification
  • ETSI SR 002 176   Electronic Signatures and Infrastructures [ESI] Algorithms and Parameters for Secure Electronic Signatures
  • ETSI TS 101 456   Policy requirements for Certification Authorities issuing Qualified Certificates
  • ETSI TS 101 861   Time Stamping profile
  • ETSI TS 101 862   Qualified Certificate [6] profile
  • ETSI TS 102 023   Electronic Signatures and Infrastructures [ESI] Policy requirements for Time Stamping Authorities
  • ETSI TS 102 040   Electronic Signatures and Infrastructures [ESI] International Harmonization of Policy Requirements for CAs issuing Certificates
  • ETSI TS 102 042   Policy requirements for Certification Authorities issuing Public Key Certificates
  • ETSI TS 102 280   X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons
  • FIPS PUB 46-3   Data Encryption Standard [DES]
  • FIPS PUB 140-2   Security Requirements For Cryptographic Modules
  • FIPS PUB 180-2   Secure Hash Standard
  • FIPS PUB 186-3   Digital Signature Standard [DSA]
  • FIPS PUB 197   Advanced Encryption Standard [AES]
  • IETF RFC 373   Arbitrary Character Sets
  • IETF RFC 1231   MD5 Hashing Algorithm
  • IETF RFC 1422   Only relating to general certificate, key management and Certificate Revokation List [CRL]
  • IETF RFC 2315   See PKCS#7 below
  • IETF RFC 2459   Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  • IETF RFC 2527   Guidelines for Certification Practice Statements [CPS] & Certificate Policies [CP]
  • IETF RFC 2560   X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
  • IETF RFC 2587   Internet X.509 Public Key Infrastructure LDAPv2 Schema
  • IETF RFC 2818   HTTP Over TLS
  • IETF RFC 2898   See PKCS#5 below
  • IETF RFC 2986   See PKCS#10 below
  • IETF RFC 3039   Internet X.509 Public Key Infrastructure Qualified Certificates Profile
  • IETF RFC 3161   Internet X.509 Public Key Infrastructure Time-Stamp Protocol [TSP]
  • IETF RFC 3279   Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
  • IETF RFC 3280   Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List [CRL] Profile
  • IETF RFC 3628   Internet X.509 Public Key Infrastructure Qualified Certificates Profile
  • IETF RFC 3629   UTF-8, a transformation format of ISO 10646
  • IETF RFC 3647   Internet X.509 Public Key Infrastructure Certificate Policy [CP] and Certification Practice Statement [CPS] Framework
  • IETF RFC 3739   X.509 Public Key Infrastructure [PKI] Qualified Certificates [6] profile
  • IETF RFC 4514   [Lightweight Directory Access Protocol [LDAP] String Representation of Distinguished Names
  • ISO/IEC 7816-15   See PKCS#15 below
  • ISO 15408   Information technology — Security techniques Evaluation criteria for IT security
  • APGridPMA   International Grid Trust Federation [IGTF [6]] Classic X.509 CAs for Asia Pacific Grid Policy Management Authority
  • EUGridPMA   International Grid Trust Federation [IGTF [6]] Classic X.509 CAs for European Union Grid Policy Management Authority
  • TAGPMA   International Grid Trust Federation [IGTF [6]] Classic X.509 CAs for The Americas Grid Policy Management Authority
  • ISO 27001   Methodology [9], Knowledge Transfer & Service
  • ITU X.509   The Directory: Public-key and attribute certificate frameworks
  • ITU-T X.520   Selected Attribute Types
  • NTP   Network Time Protocol
  • HTTP   Hypertext Transfer Protocol
  • HTTPS   Hypertext Transfer Protocol Secure
  • PKCS#1   RSA Cryptography Standard: this standard defines the RSA cryptography
  • PKCS#5   Password-Based Cryptography Standard: this standard defines how to encrypt/decrypt data using passwords
  • PKCS#7   Cryptographic Message Syntax Standard: this standard describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes
  • PKCS#8   Private-Key Information Syntax Standard: this standard describes a syntax for private-key information where private-key information includes a private key for some public-key algorithm and a set of attributes.
  • PKCS#9   Selected Object Classes and Attribute Types: this standard this standard defines two new auxiliary object classes, pkcsEntity and naturalPerson, and selected attribute types for use with these classes.
  • PKCS#10   Certification Request Syntax Standard: this standard describes syntax for certification requests where a certification request consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification.
  • PKCS#11   Cryptographic Token Interface Standard: this standard specifies an application programming interface (API), called “Cryptoki,” to devices which hold cryptographic information and perform cryptographic functions.
  • PKCS#12   Personal Information Exchange Syntax: this standard describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions.
  • PKCS#15   Applies to smart card vendors
         

    HSM

     

    Hardware Security Module [HSM]

         
  • Common Criteria   HSM Hardware, HSM vendor should further confirm the compliance
  • EAL   HSM Hardware, HSM vendor should further confirm the compliance
  • FIPS 140   Security Requirements for Cryptographic Modules (HSM and Smart Card vendors to provide further confirmation on this compliance)
         

    Smart Cards

     

    Cryptographic Service Provider [CSP]

  • ISO 7816 Parts 1 - 5   Smart Card Operating System Transport Application Parts 1 - 5
  • ISO 7816 Parts 7 - 9   Smart Card Operating System Transport Application Parts 7 - 9
         
  • EAL4+   HSM and Smart Card vendors to provide further confirmation on this compliance
  • FIPS 140 Validated   HSM and Smart Card vendors to provide further confirmation on this compliance
  • ISO 7816 1-5 Compatible   Microcontroller and supplementary Numeric Processing Unit [NPU] capable of calculating cryptographic operations according to PKCS #11 and PKCS #15 according to ISO/IEC 7816-1 to 7816-5 requirements
  • 32 bit crypto processor   For improved card performance and usability
  • Support for RSA 1024/2048 bits   Key length capabilities
  • Support for DES algorithm   Symmetric Algorithm
  • Support for 3DES algorithm     Symmetric Algorithm
  • CSP software   Cryptographic Service Provider [CSP] on chip OS capable of performing cryptographic functions
         

    Development Roadmap

     

    Pending Compliance

  • EEC   Elliptical Curve Cryptography
  • SCVP   Server-based Certificate Validation Protocol
  • ICAO MRTD   International Civil Aviation Organisation [ICAO], PKI for Machine Readable Travel Documents [MRTD] offering ICC Read-Only Access
  • XKMS   XML Key Management Services
  • Lightweight OCSP   Lightweight Online Certificate Status Protocol [OCSP] Profile for High-Volume Environments
  • Digi-Card OS   Development of proprietary smart card Operating System [OS]


Standards Outlined

Third-Party Certifications & Standards Compliance


  • PDF [1] 45 CFR Part 162
    HIPAA Administrative Simplification: Standard unique Health Identifier for Health Care Providers; Final Rule

  • BS7799 – Specification for an Information Security Management System 9subject to environment, perimeter and network security provisions

  • FIPS 140-2 Level 1,2,3 & 4
    Security requirements for Cryptographic Modules that integrate easily with the Digi-CA™ system

  • PKCS#11compliance [10] [Cryptographic Token Interface Standard]
    Specification for an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions

  • PKCS#12 compliance [Personal Information exchange Syntax Standard
    Specification of a portable format for storing or transporting a user's Private Keys, certificates, miscellaneous secrets, etc.

  • PKCS#15 compliance [Cryptographic Token Information Format Standard]
    Standard that enables users to use cryptographic tokens to identify themselves to multiple, standards [10]-aware applications, regardless of the application's cryptoki (or other token interface) provider.

  • 1999/93/EC [11] EU Law
    European Legislation for the issuance of EU Qualified Certificates that have legal standing and can be used in a court of law within any EU State

  • ETSI 101 456
    Technical Specification and Policy requirements for Certification Authorities issuing Qualified Certificates

  • CWA 14167-1
    Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 1: System Security Requirements

  • CWA 14167-2
    Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 2: Cryptographic Module for CSP signing operations with backup - Protection profile (CMCSOB-PP)

  • CWA 14169
    Secure Signature-creation devices "EAL 4+"

  • CWA 14171
    General guidelines for electronic signature verification

  • ETSI 101 862
    Qualified Certificate Profile

  • ETSI 101 861
    Qualified Certificate Profile


1999/93/EC

Under the EU Electronic Signatures Directive for Qualified Electronic Signatures and National Certification Service Providers issuing Qualified Certificates [6] to the public, Digi-Sign is listed under Ireland [6].

PDF [1] By virtue of the fact that the Digi-CA™ and Digi-CAST™ [9] Team ensure that the

            • ETSI 101 456,
            • ETSI 002 176,
            • ETSI 102 023,
            • ETSI 101 861,
            • CWA 14167-1,
            • CWA 14172-3,
            • CWA 14890,
            • CWA 14169 / ISO 15408,
            • CWA 14171,
            • PKCS#11,
            • PKCS#12,
            • PKCS#15,
            • IETF RFC 2527
            • and IETF RFC 3647

standards are complied with, Digi-CA™ [2] complies with

            • Annex I,
            • Annex II,
            • Annex III
            • and Annex IV

of this Community framework journal.

CWA Standards

PDF [1] 7.5 CWA 14167-1
7.6 CWA 14172-3
7.7 CWA 14890
7.8 CWA 14169 / ISO 15408
7.9 CWA 14171

CWA 14167-1

PDF [1] In compliance with CWA 14167-1, Section 5.1.2 SO1.1, the Digi-CA™ and Digi-CA™ Xg Trust Centre documentation provides documented instructions for the installation, administration and usage of the Digi-CA™ systems.

In compliance [10] with CWA 14167-1, Section 5.1.2 SO2, Digi-CA™ [2] can be configured to ensure business continuity so that services are quickly and securely restored in case of failure of the Digi-CA™ system.

In compliance with CWA 14167-1, Section 5.1.2 SO2.1, the Digi-CA™ provides for availability of the system services operation at 99.9% availability on a monthly basis and also ensures the following:

            • Dissemination Service
            • Revocation Management Service
            • Revocation Status Service



In compliance with CWA 14167-1, Section 5.1.2 SO2.2 and SO2.3, the Digi-CA™ enables the continued operation of the Digi-CA™ because the entire system is replicated to a second set of Digi-CA™ servers and if required the entire Digi-CA™ can be migrated to a totally new Digi-CA™ environment at an acceptable level of risk because the information stored in the previously live system was publicly available information only.

In compliance with CWA 14167-1, Section 5.1.2 SO3, the Digi-CAST2™ Team will document the accuracy of the Time Stamping Device [12] once it is installed and tested and two sources of atomic clock are used to perform this task.

In compliance with CWA 14167-1, Section 5.1.3.1, the Digi-CA™, using two factor authentication [13] where applicable and defined administration roles, only authorized persons have any access to the system.
In compliance with CWA 14167-1, Section 5.1.3.2 IA1.1-3 & IA2, the Digi-CA™ requires each user to be identified and to be successfully authenticated before they are allowed any action on behalf of that user or role assumed by the user. There must be re-authentication after log-out and the authentication data, where used, is unique and cannot be reused.

In compliance with CWA 14167-1, Section 5.1.3.2 IA2.1-2, if the number of unsuccessful authentication attempts equals or surpasses the maximum number of allowed attempts, the Digi-CA™ system prevents further authentication attempts and if the number of unsuccessful authentication attempts equals or surpasses the maximum number of allowed attempts, and the role is that of an administrator, then a notification event is logged by the system and the access is denied until two alternative authorized personnel conduct and audit of the event and reinstate the Administrator who’s access has been denied.

In compliance with CWA 14167-1, Section 5.1.3.2 IA3.1, the probability of guessing any secret defined for any component of the Digi-CA™ is negligible.

In compliance with CWA 14167-1, Section 5.1.4.1, the system access control functions control the use of objects of the Digi-CA™ to authorized persons only. This applies to all sensitive objects of the Digi-CA™. System access control is provided by the underlying operating software and access rights to specific Digi-CA™ objects are determined by the owner of the object based on the identity of the subject attempting the access and the access rights to the object granted to the subject or the privileges held by the subject.

In compliance with CWA 14167-1, Section 5.1.4.2 SA1, the Digi-CA™ provides the capability of controlling and limiting access by identified individuals to the system/user objects they own or are responsible for and ensures they provide access protection to sensitive residual information by using secure, cryptographic based authentication methods along with defined administration roles.

In compliance with CWA 14167-1, Section 5.1.5.1, Digi-CA™ uses cryptographic keys to provide integrity, confidentiality and authentication functions within its own subsystems and in between subsystems and throughout the key life cycle management of private and/or secret keys is carried out securely.


The Digi-CA™ keys are separated into the following categories:

    1. ALL Signing Keys - Digi-CA’s™ key pair for producing Qualified Digi-IDs™ or Non-Qualified Digi-IDs™ and keys for signing certificate status information.

    2. Infrastructure Keys – these are keys used by the Digi-CA™ for processes such as key agreement, subsystem authentication, audit log signing, encrypting transmitted or stored data, etc. Short term session keys are not categorized as Infrastructure keys

    3. Digi-CA™ Control Keys – these are keys used by personnel managing or using the Digi-CA™ and may provide authentication, signing or confidentiality services for those personnel interacting with the system.

    In terms of security requirements, ALL Signing Keys are long-term keys whose impact from exposure is high. Consequently, countermeasures for managing this risk are also high, both in number and in effect. Infrastructure keys are also considered high risk but due to their distributed functionality and shorter lifespan they are a lower risk in comparison to signing keys. The lowest risk keys, used by the Digi-CA™, are considered to be those used by personnel for controlling the Digi-CA™, as these are used by trusted individuals and have an even shorter lifespan. Session keys, used for single/short transactions are treated as sensitive information but with lower security requirements to the above stated categories.

Infrastructure and Control keys may be either asymmetric or symmetric keys.

    Key Generation

    Key Generation refers to the creation of keys.


    Key Distribution

    All Key Distribution is the function of distributing the Digi-CA’s™ Public Key, Infrastructure or Control keys.


    Key Usage

    This is the controlling of usage of generated keys within cryptographic algorithms to provide cryptographic services.


    Key Change

    Key change may be:


              • Programmed - where a key is replaced by a newly generated key once it reaches the end of its operational life (as determined by policy)
              • Non-Programmed – where a key is replaced by a newly generated key if it has been compromised.



    Key Destruction

    When a key is compromised or when it reaches the end of its operational life it may be destroyed to prevent any further use of the key.


    Key Storage, Backup & Recovery

    After Key Generation, the keys may be stored in secure environments and may be copied and backed up to meet operational requirements. These backed up keys may need to be recovered when for example the existing key is inadvertently destroyed.


CWA 14167-2

Key Archival

PDF [1] At the end of a key’s operational life it may be archived to allow use of the key at some later (undefined) time. This is specifically in reference to Public Keys used to verify digital signature [14] but does not preclude archiving of other types of keys where justified.

In compliance [10] with CWA 14167-1, Section 5.1.5.2 KM1.1-7, Digi-CA™ [2] is configured to work with Eracom and nCipher HSMs and these HSMs comply with this standard whilst the Digi-CA™ ensure Infrastructure and Control Keys are generated and maintained in the HSM. All key generation meets the cryptographic requirements specified in [ALGO].

In compliance with CWA 14167-1, Section 5.1.5.2 KM2.1-2.4, the Digi-CA™ private and secret keys are not distributed in plain text and Public Keys that have not been certified are kept secure to prevent interception or manipulation and the Digi-CA™ distributes the cryptographic keys in accordance with either the package or process cryptographic key distribution method.

The Public Key associated with all the Signing Keys and/or Infrastructure Keys (e.g. Revocation Status Service, Time-Stamping Service) can be made available to Subjects and Relying Parties. The integrity and authenticity of this Public Key and any associated parameters is maintained during initial and subsequent distribution.

In compliance with CWA 14167-1, Section 5.1.5.2 KM2.5, the Digi-CA™ the SSRoot is verifiable using data provided within the Digi-ID™ [15] and the Digi-ID™ subject and issuer fields are identical.

In compliance with CWA 14167-1, Section 5.1.5.2 KM2.6, the Digi-CA™ is capable of producing a fingerprint of a self-signed certificate using the hashing algorithms defined in [ALGO].

In compliance with CWA 14167-1, Section 5.1.5.2 KM3.1-3, access controls to the Digi-CA™ are in place for all secure cryptographic modules used for all signing, infrastructure and control keys. The Digi-CA™ provides support for dual-person control when using control keys and this provides administration functionality of the Digi-CA™. Separate infrastructure keys are generated for separate functions and infrastructure keys associated with the Registration Service, Digi-CA™ and the Revocation Management Service are not shared.

In compliance with CWA 14167-1, Section 5.1.5.2 KM3.4-5, the Subject Device Provision Service, ensures that the subject keys for creating the Digi-IDs™ are separate from those used for other functions and that the key usage extension is present in the signature certificate being issued. If the key usage non Repudiation bit is asserted then it is not combined with any other key usage and authorised key usage only occurs within the operational life of the key.

In compliance with CWA 14167-1, Section 5.1.5.2 KM3.6, before the Digi-CA™ relies on Digi-IDs™ for asymmetric infrastructure or controls keys they ensure that the Digi-IDs™ related to these keys are still valid and this is done by checking the CRL.

In compliance with CWA 14167-1, Section 5.1.5.2 KM4.1-2, the Digi-CA™ enables the infrastructure and control keys to be changed on a regular basis and if any of the algorithms used in the Digi-CA™ are considered to have become unsuitable (as specified in [ALGO]), keys based on those algorithms are changed immediately. Key changeover is carried out securely and requires an out-of-band change.

In compliance with CWA 14167-1, Section 5.1.5.2 KM5.1-2, when all the Signing Keys reach the end of their life they are destroyed such that the signing keys cannot be retrieved and when the systems have been used to generate, use or store secret/Private Keys and are to be withdrawn from service or transferred their associated keys they too are destroyed.

In compliance with CWA 14167-1, Section 5.1.5.2 KM5.3-4, the Digi-CA™ provides the capability to zeroise plaintext secret and Private Keys stored in both the hardware and the software and the software key destruction is carried out using secure wiping processes that positively overwrite the keys.

In compliance with CWA 14167-1, Section 5.1.5.2 KM6.1-3, the Digi-CA™ facilitates the secure storage of all Private Keys and in conjunction with the HSM all the Signing Key are stored in, as is the private/secret infrastructure and control.

In compliance with CWA 14167-1, Section 5.1.5.2 KM6.4, if any private/secret key in a secure cryptographic module or HCD is exported from that module, it is protected by the module, to ensure its confidentiality, before being stored outside that module and any other sensitive key material is never be stored in an unprotected state.

All Signing Keys of the Digi-CA™ may be stored and backed up only when additional security mechanisms are in place. For instance, this may be accomplished using m of n techniques, where m component parts out of a total of n component parts are required for successful key initialization. For recovery from failure purposes, it is recommended that m= 2. If n = 4, then m = 3, if n = 5, then m = 3, etc.

In compliance with CWA 14167-1, Section 5.1.5.2 KM6.5-7, the Digi-CA™ ensures that backup, storage and restoration of private/secret NQC/QC Signing, Infrastructure and Control Keys is only performed by authorized personnel (e.g. Security Officer role) and ensures that backup, storage and restoration of private NQC/QC Signing Keys is only performed at least under dual-person control and does not contain functions that allow for backup or escrow of Subject signature keys (Private Keys).

In compliance with CWA 14167-1, Section 5.1.5.2 KM7.1, the Digi-CA™ does not contain functions that allow for backup or escrow of Subject signature keys (Private Keys).

In compliance with CWA 14167-1, Section 5.1.5.2 AA1.1, the Digi-CA™ logs the following:


            • Significant environmental, key management and Digi-ID™ management events
            • Start-up and shut-down of the audit data generation function
            • Changes to the audit parameters
            • Actions taken due to audit storage failure
            • All access attempts to the Digi-CA™ are logged



In compliance with CWA 14167-1, Section 5.1.5.2 AA2.1-2, the Digi-CA™ system maintains audit data and guarantee sufficient space is reserved for that data and the audit log cannot be automatically overwritten.

In compliance with CWA 14167-1, Section 5.1.5.2 AA3.1, the Digi-CA™ system service specific audit logging for all audit records that contain the following parameters:


            • date and time of event
            • type of event
            • identity of the entity responsible for the action
            • success or failure of the audited event



In compliance with CWA 14167-1, Section 5.1.6 AA4.1-2, the Digi-CA™ provides the capability to search for events in the audit log based on the date and time of event, type of event and/or identity of the user and the audit records are presented in a manner suitable for the user to interpret the information.

In compliance with CWA 14167-1, Section 5.1.6 AA4.1-2, the Digi-CA™ prohibits all user read access to the audit records, except those users that have been granted explicit read access (e.g. those with System Auditor role) and modifications of the audit records is prevented.

In compliance with CWA 14167-1, Section 5.1.6 AA6.1, the Digi-CA™ generates an email alarm to the Security Officer upon detection of a potential or actual security violation.

In compliance with CWA 14167-1, Section 5.1.6 AA7.1, the Digi-CA™ ensures the integrity of the audit data for non qualified Digi-IDs™ and for qualified Digi-IDs™ ensures the integrity of the audit data by providing a digital signature, keyed hash or an authentication code with each entry in the audit log, computed over the entire audit log or over the current entry and the cryptographic result of the previous one and also provides a function to verify the integrity of the audit data.

In compliance with CWA 14167-1, Section 5.1.6 AA8.1, the Digi-CA™ the use of a trusted time source that is used to mark the time of audited events.

In compliance with CWA 14167-1, Section 5.1.7 AR1.1-4, the Digi-CA™ is capable of generating an archiving on media appropriate for storage and subsequent processing in providing necessary legal evidence in support of electronic signatures. Each entry includes the time at which the event occurred and does not include critical security parameters in an unprotected form. The following items are archived:


            • All Digi-IDs™
            • All CRLs/ARLs
            • All Audit logs



In compliance with CWA 14167-1, Section 5.1.7 AR2.1, the Digi-CA™ provides the capability to search for events in the archive based on the type of events.

In compliance with CWA 14167-1, Section 5.1.7 AR3.1, the Digi-CA™ ensures each entry in the archive is protected from modification.

In compliance with CWA 14167-1, Section 5.1.8 BK1.1-3, the Digi-CA™ includes a backup function so that the data stored in the backup is sufficient to recreate the state of the system and a user linked to a role with sufficient privileges is capable of invoking the backup function on demand.

In compliance with CWA 14167-1, Section 5.1.8 BK2.1-2, the Digi-CA™ backups are protected against modification and are protected against modification through use of digital signatures, keyed hashes or authentication codes. Critical security parameters and other confidential information is stored in encrypted form only and the encryption meets the cryptographic requirements specified in [ALGO].

In compliance with CWA 14167-1, Section 5.1.8 BK3.1-2, the Digi-CA™ include a recovery function that is able to restore the state of the system from a backup and a user linked to a role with sufficient privileges is capable of invoking the recovery function on demand.

In compliance with CWA 14167-1, Section 5.2.1 GE1, the Digi-CA™ ensures that all messages created by any core service is protected (e.g. by using message authentication codes, digital signatures, etc.) by using the service’s Infrastructure Keys, contains a message time, to indicate the time at which the sender created the message and includes replay attack protection (e.g. by using nonces).

In compliance with CWA 14167-1, Section 5.2.2.1, the Digi-CA™ ensures that the Digi-ID™ application is carried out by the Registration Service after identification of the Subject has been carried out meeting the requirements specified in the associated Certificate Policy in accordance with ETSI 101 456 and that the Registration Service by its nature manages end entity subject data that may be affected by many different data protection requirements.

In compliance with CWA 14167-1, Section 5.2.2.2 R1, the Digi-CA™ ensure that if the Digi-ID™ application contains any subject sensitive information, the Digi-ID™ request is protected before being forwarded from the Registration Service to the Digi-CA™ thus ensuring message confidentiality but this functionality is only provided if required by the customer or the local legislation in the territory where the Digi-CA™ Xg Trust Centre resides.

In compliance with CWA 14167-1, Section 5.2.2.2 R1.2, the Digi-CAST3™ Team will ensure that the service implements a suitable mechanism to obtain proof-of-possession (POP) to ensure the entity requesting Certification is the actual holder of the Private Key related to the Public Key requiring Certification (an example of this would be to include a signature block with each Digi-ID™ application, which is created by the Private Key associated with the Public Key requiring Certification. Suitable algorithms for creating the signature are detailed in [ALGO]).

In compliance with CWA 14167-1, Section 5.2.2.2 R1.3-4, the Digi-CAST3™ Team will ensure that the Registration Service is be configured to allow collection of enough data from the subject to satisfy the requirements for QCs as specified in Annex I of [Dir.1999/93/EC]. And the Digi-CA™ provides a mechanism to allow approval of Digi-ID™ applications using the RA Control Centre, by a Registration Officer, before leaving the Registration Service.

In compliance with CWA 14167-1, Section 5.2.2.2 R1.3-4, the Digi-CAST3™ Team will ensure that the Registration Service notes the time of the application and the information publication control to allow subjects to control the Digi-CA’s™ publication of the QC via the Dissemination Service.

In compliance with CWA 14167-1, Section 5.2.2.2 R1.6, the Digi-ID™ requests from the Registration Service are digitally signed for authentication and data integrity using its Infrastructure or Control Keys.

In compliance with CWA 14167-1, Section 5.2.2.2 R2.1, the Digi-CA™ implements mechanisms and security controls to protect the privacy and confidentiality of Subject information.

In compliance with CWA 14167-1, Section 5.2.2.2 R3.1, the Digi-CA™ logs all events relating to registration including Digi-ID™ re-key/renewal requests and approved requests for Certification.

In compliance with CWA 14167-1, Section 5.2.3.1, when using the Package Method, the Digi-CA™ generates the Digi-ID™ using the Public Key supplied. This ensures the CSP has ‘locked’ the binding of the Subject’s Public Key to its identity.

During the period prior to the expiration of the Digi-ID™, such period being defined by the Certificate Policy, the Digi-CA™ renewal of the new Digi-ID™ is produced using the existing Public Key or a re-key using the registration information used to generate the previous Digi-ID™. Digi-ID™ renewal covers Infrastructure, Control and Subject Digi-IDs™.

CWA 14167-3

PDF [1] In compliance with CWA 14167-1, Section 5.2.3.2 CG1.1-3, the Digi-CA™ ensures the integrity, data origin authenticity, and where necessary, the privacy and confidentiality of the Digi-ID™ [15] request message and the Digi-ID™ request is processed securely and checked for conformance with the applicable Certificate Policy. Before the Digi-ID™ generation, the Digi-CA™ [2] ensures Proof of Possession is validated.

In compliance [10] with CWA 14167-1, Section 5.2.3.2 CG1.4-6, the key used to sign a QC is only used for signing QCs and, optionally, the related Revocation Status Data and this service only generate Digi-IDs™ that are consistent with the allowed profiles as determined by the Security Officer. All Digi-IDs™ have the following properties:

    1. Indication of the subject’s name or pseudonym and where a pseudonym is used this is clearly indicated
    2. The Public Key in the Digi-ID™ is related to the subject’s Private Key
    3. The advanced electronic signature of the Trust Centre created using the Trust Centre Signing Keys
    4. A unique distinguished name and serial number assigned by the Digi-CA™ that is unique with respect to the issuing Trust Centre
    5. The Digi-ID™ specifies a valid from time that does not precede the current time and a valid until time that does not precede the valid from time
    6. The signature algorithms/keys used by the Digi-CA™ to sign the Digi-ID™ is conformant to the algorithm specifications standard [ALGO]
    7. Reference to the Certificate Policy under which the Digi-ID™ is issued
    8. All qualified Digi-IDs™ issued by a Digi-CA™ conform to ETSI 101 862.



In compliance with CWA 14167-1, Section 5.2.3.2 CG2.1-2, for re-certification [10], the Digi-CA™ ensures process security against Digi-ID™ substitution attacks and the re-certification of Control and Infrastructure Digi-IDs™ with 5.1.5.2 KM.4 - Key Change.

In compliance with CWA 14167-1, Section 5.2.3.2 CG2.3, the Digi-CA™ ensures that all the Signing Keys are updated prior to their expiry. The related (renewed) Public Keys provide at least the same level of trust as when they were initially distributed. This is accomplished by providing at least the following intermediary certificates to prove possession of the new Private Key as follows:

    1. Providing a Digi-ID™ of the old Public Key signed with the new Private Key

    2. Providing a Digi-ID™ of the new Public Key signed with the old Private Key

    3. Providing the new self signed Digi-ID™ (signed with the new Private Key)



In compliance with CWA 14167-1, Section 5.2.3.2 CG2.4, the Digi-CA™ re-certifying and/or re-keying of Subject keys, is as secure as the initial certificate generation and the Subject Certificates are renewed prior to their expiry. The Digi-CA™ automatically rejects a renewal request signed with an expired or revoked key.

In compliance with CWA 14167-1, Section 5.2.3.2 CG4.1, the Digi-CA™ logs the following events:

  • All events relating to the life cycle management of all Signing, Infrastructure and Control Certificates
  • All events relating to the life cycle management of all Signing keys
  • All events relating to the life cycle management of Subject Certificates



In compliance with CWA 14167-1, Section 5.2.4.1 D1.1-2, the Digi-ID™ dissemination by the Digi-CA™ is limited to the Subject, and to Relying Parties according to the limits expressed by the Subject and the dissemination process manages the Digi-IDs™ accordingly.

In compliance with CWA 14167-1, Section 5.2.4.1 D2.1, if a repository is set up, an access control policy is defined to securely manage the access to stored data and read access privileges are granted to Subjects and to authorised entities according to the rules defined by the Subject and the Security Policy whilst write access privileges are limited to authorised roles, according to the definition of roles proposed in 5.1.1.

In compliance with CWA 14167-1, Section 5.2.5.2 RM1.1-6 and RM 2.1, requests and reports relating to revocation and/or suspension are processed by the Digi-CA™ in a timely manner and the maximum delay between receipt of a revocation and/or suspension request and the change to Digi-ID™ status information does not exceed 24 hours.

All requests for suspension, reinstating and revocation is authenticated and validated and once a Digi-ID™ is definitely revoked the Digi-CA™ ensures that it cannot be reinstated. Revocation of certificates related to all Signing Keys is only possible under at least dual control and status changes can be instigated by authenticated:

  • CSP Security Officers for Infrastructure/Control Certificates
  • Registration/Security Officers for Subject Certificates;
  • Subjects for their own certificates



The Certificate Status database is updated immediately after request/report processing is complete. The Digi-CA™ is able to revoke any Digi-ID™ it has issued, even after a disaster.

In compliance with CWA 14167-1, Section 5.2.5.2 RM2.2, where Periodical Messaging is used, the Digi-CA™ supports the following requirements:

  • For an offline status repository (e.g. CRL accessible through directories) the Revocation Status Service is updated at least on a daily basis
  • For an online status repository (e.g. OCSP [16] responder) the Revocation Status Service is updated when a status change occurs and additionally at least on a daily basis
  • Each update message includes the name and digital signature [14] of the message issuer, and the time of status change
  • The messages only indicates the Digi-IDs™ that are revoked/suspended
  • For each Digi-ID™ in the list, its serial number and a reason for the status change is provided in the message
  • In compliance with CWA 14167-1, Section 5.2.5.2 RM2.3 and RM3.1, where Real-Time Messaging is used, the Digi-CA™ meets the following requirements:

  • Where the Revocation Status Service queries a certificate status, the Certificate Status database MUST reply by providing the current status of that certificate
  • A trusted channel (Fig1: Message B) MUST exist between the Revocation Management Service and the Revocation Status Service
  • This trusted channel MUST be configured to minimise denial of service attacks on the messaging
  • Request and response messages MUST be protected from replay attacks (e.g. by using nonces).



And all events related to certificate status change requests, whether approved or disapproved, are logged.
In compliance with CWA 14167-1, Section 5.2.6.2 RS1.1-3, Real-time or Periodic Messages provided to this service are only from trusted Revocation Management Services and if the Digi-CA™ is providing an ‘online’ revocation status service, it validates the integrity and authenticity of Real-time or Periodic messages sent to it and it ensures that replies to responses from the Certificate Status database are for the requested certificates.

In compliance with CWA 14167-1, Section 5.2.6.2 RS2.1-4 and 3.1, all certificate status responses from the ‘online’ Revocation Status Service are digitally signed by the Revocation Status Service using its infrastructure keys and signature algorithms/keys used for status response are compliant with [ALGO]. The response message contains the time at which the Revocation Status Service/Issuer signed the response. All ‘online’ Revocation Status Service certificate status requests and responses are logged.

In compliance with CWA 14167-1, Section 5.3.1.2 TS1.1-2, the Digi-CA™ controls the origin of each request before checking its correctness and verifies that the request for time stamping uses a hash algorithm that is specified as approved by [ALGO].

In compliance with CWA 14167-1, Section 5.3.1.2 TS2.1-2, the Digi-CA’s™ trusted time source(s) are synchronised to Co-ordinated Universal Time (UTC) within the tolerance dictated by Certificate Policy e.g. to within 1 second and this is the same source as specified in requirement SO3 and the Digi-CA™ clock is synchronised with the UTC using a mechanism that is demonstrated to be reliable.

In compliance with CWA 14167-1, Section 5.3.1.2 TS3.1-3, the Serial Number used within the time stamping token is unique for each token issued by Digi-Sign and this property is preserved even after a possible interruption of the service. As well as Time Parameter inclusion, the time stamping token includes the accuracy of the time source used if this is exceeds that required by the time stamping policy. An indication of the policy under which the time stamping token was created is included.

In compliance with CWA 14167-1, Section 5.3.1.2 TS4.1-6, the Time Stamping Authority [TSA] Signing Keys are generated and stored in a secure cryptographic module and the cryptographic module of fulfils the requirements of KM 1.2. The TSA Control Keys are stored in a hardware cryptographic device (HCD) and the TSA Signing Key is only used for signing time stamping tokens produced by the TSA. The TSA ensures that the time stamping token’s response contains the same datum that was sent with the request and that the signature algorithms/keys used by the TSA meets the cryptographic requirements specified in [ALGO].

In compliance with CWA 14167-1, Section 5.3.2.2 TS5 and 6, the following Time-Stamping [17] Service specific events are logged:

  • All events relating to TSA Certificate re-key/renewal requests
  • All events relating to the life cycle management of the TSA Signing Key
  • All failures (including time drift outside of allowed tolerance) associated with the trusted time sources.



And all Time-Stamp Tokens are archived in accordance with [AR 1.1].

In compliance with CWA 14167-1, Section 5.3.1.2 SP1-4, the Eracom and nCipher HSMs meet this criteria as certified in their FIPS accreditation and as the key pairs are generated within these certified HSMs this satisfies the requirement.

CWA 14172-3

PDF [1] On the basis that the Trust Centre achieves certification to BS 7799 or ISO 17799, the Digi-CA™ Administrators and Operators will have passed the required training and certification for the correct conduct and security practices required to work in the Digi-CA™ Xg Trust Centre.

CWA 14890

PDF [1] Digi-CA™ [2] uses vendor specific Cryptographic API to import keys and certificates into the Digi-Card™. The Digi-CA™ does not participate in the certificate usage process, which means that it does not provide applications that will use the card interface and installed keys and certificates to sign any data. On the assumption that only CWA 14890 compliant Digi-Cards™ are used in conjunction with the Digi-CA™, by association, Digi-CA™ complies with this standard.

CWA 15579

PDF [18] In compliance with CWA 15579 Digi-Bill™ uses both Qualified and non-Qualified Digital Signatures, as required by your national law. It also complies with 2001/115/EC [6], CWA 15580 [19] and CWA 15588 [20].

According to the Council Directive 2001/115/EC [2] “invoices sent by electronic means shall be accepted by Member States provided that the authenticity of the origin and integrity of the contents are guaranteed”. This could be guaranteed “by means of an advanced electronic signature within the meaning of Article 2 (2) of Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures; Member States may however ask for the advanced electronic signature to be based on a qualified certificate and created by a secure signature creation device, within the meaning of Article 2(6) and (10) of the aforementioned Directive”.

It further states that: “Authenticity of the origin and integrity of the content has to be guaranteed when using electronic data interchange (EDI) as defined in Commission Recommendation 1994/820/EC of 19 October 1994 relating to the legal aspects “when the agreement relating to the exchange provides for the use of procedures guaranteeing the authenticity of the origin and integrity of the data”. However, as per the Directive [2]: “Member States may, subject to conditions which they lay down, require that an additional summary document on paper is necessary” to be exchanged, summarising a set of invoices. Where the applicable law allows for it this summary document could also be exchanged electronically. It is to be remarked that usage of EDI is subject to meeting the previously italicised wording. To exchange this summary document electronically also electronic signatures can be used to guarantee authenticity of the origin and integrity”.

In compliance with CWA 15579, the Digi-Bill™ uses the required advanced electronic signature and timestamp and also ensures that:

  • Generation of the electronic signatures for electronic invoices must be possible also in an automated and reliable process that is law abiding
  • Digi-Sign Can act on behalf of a taxable entity
  • Enough information is provided to ensure long term validity to the electronic signatures of the electronic invoices, the origin and integrity of the content of the invoices and that their their readability is guaranteed throughout the storage period


    • References & Supporting Standards

      In compliance with CWA 15579, Digi-Bill™ complies with these supporting standards:


      • x.509 Standard
      • Certificate Policy [CP] is indicated
      • The OID of which is written in the certificatePolicies extension
      • x.500 attribute as specified in X.520 [6] and in X.521 [7] is used
      • The VAT code of the entity issuing the invoice can be added
      • The private key related to the certified public key resides in a Secure Signature Creation Device
      • Invoices can be archived from 4 to 11 years, as required
      • The CP permits the use and issue of single signatures and automated signatures


CWA 14169 / ISO 15408

PDF [1] Digi-CA™ is configured to work many HSMs (nCipher, SafeNet, etc) and as this standard relates to the use of the Secure Signature Creation Device [SSCD] found in HSMs, the fact that these devices meet the standards [10] means that by association, Digi-CA™ complies with this standard.

CWA 14171

PDF [1] The Digi-CA™ complies with this standard by virtue of the fact that its Digi-IDs™ can be opened, examined and read by persons or handicapped persons using the functions within a standard Windows® PC and all of the required information in this standard is made available for this person to verify the Digi-ID™ [15].

With regard to the security requirements for the Digi-ID™ verification systems on the understanding that the Digi-CAST2™ Team conduct the installation, the integrity and authenticity of hardware and software are supervised at all stages and the security-relevant data and processes in secure areas is protected against unauthorised modification. If any unauthorised modification of the secure area hardware components occurs, the Digi-CAST2™ Team are trained to recognise them.

The components of the signature verification system use a combination of trusted devices and other hardware and software that are both physically secured and tested after installation using the checks and Procedures of the Digi-CAST2™ Team.

CWA 15579

Compliance with EU Directive on eInvoice Legislation

PDF [18] In compliance with CWA 15579 Digi-Bill™ uses both Qualified and non-Qualified Digital Signatures, as required by your national law. It also complies with 2001/115/EC [6], CWA 15580 [19],CWA 15581 [21] and CWA 15582 [22].

According to the EU Council Directive 2001/115/EC [2] “invoices sent by electronic means shall be accepted by Member States provided that the authenticity of the origin and integrity of the contents are guaranteed”. This could be guaranteed “by means of an advanced electronic signature within the meaning of Article 2 (2) of Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures; Member States may however ask for the advanced electronic signature to be based on a qualified certificate and created by a secure signature creation device, within the meaning of Article 2(6) and (10) of the aforementioned Directive”.

It further states that: “Authenticity of the origin and integrity of the content has to be guaranteed when using electronic data interchange (EDI) as defined in Commission Recommendation 1994/820/EC [6] of 19 October 1994 relating to the legal aspects “when the agreement relating to the exchange provides for the use of procedures guaranteeing the authenticity of the origin and integrity of the data”. However, as per the Directive [2]: “Member States may, subject to conditions which they lay down, require that an additional summary document on paper is necessary” to be exchanged, summarising a set of invoices. Where the applicable law allows for it this summary document could also be exchanged electronically. It is to be remarked that usage of EDI is subject to meeting the previously italicised wording. To exchange this summary document electronically also electronic signatures can be used to guarantee authenticity of the origin and integrity”.

In compliance with CWA 15579, the Digi-Bill™ uses the required advanced electronic signature and timestamp and also ensures that:

  • Generation of the electronic signatures for electronic invoices must be possible also in an automated and reliable process that is law abiding
  • Digi-Sign can act on behalf of a taxable entity
  • Enough information is provided to ensure long term validity to the electronic signatures of the electronic invoices, the origin and integrity of the content of the invoices and that their their readability is guaranteed throughout the storage period


    • References & Supporting Standards

      In compliance with CWA 15579, Digi-Bill™ complies with these supporting standards:


      • x.509 Standard
      • Certificate Policy [CP] is indicated
      • The OID of the CP is written in the certificatePolicies extension
      • x.500 attribute as specified in X.520 [6] and in X.521 [7] is used
      • The VAT code of the entity issuing the invoice can be added
      • The private key related to the certified public key resides in a Secure Signature Creation Device
      • Invoices can be archived from 4 to 11 years, as required
      • The CP permits the use and issue of single signatures and automated signatures
      • Compliance with ETSI TS 101 861 [23] Time stamping profile
      • Compliance with ETSI 102 023 [24] Time stamping profile


CWA 15580

Compliance with EU Directive on eInvoice Storage

PDF [18] In compliance with CWA 15580 Digi-Bill™ complies with 2001/115/EC [6], CWA 15579 [25], CWA 15581 [21] and CWA 15582 [22].

According to the EU Council Directive 2001/115/EC [2] “regarding the storage of Invoices, every taxable person shall ensure that copies of invoices issued by himself, by his customer or, in his name and on his behalf, by a third party, and all the invoices which he has received, are stored”. This could be guaranteed “The authenticity of the origin and integrity of the content of the invoices, as well as their readability, must be guaranteed throughout the storage period. With regard to invoices that are not sent under either an advanced electronic signature, or by EDI (i.e. the “third option” – “by other electronic means”), the information they contain may not be altered and must remain legible throughout the aforementioned period”.

In compliance with CWA 15580, the Digi-Bill™ uses the required advanced electronic signature and timestamp and also ensures that:

  • Enough information is provided to ensure long term validity to the electronic signatures of the electronic invoices, the origin and integrity of the content of the invoices and that their their readability is guaranteed throughout the storage period
  • Generation of the electronic signatures for electronic invoices must be possible also in an automated and reliable process that is law abiding
  • Digi-Sign can act on behalf of a taxable entity


    • References & Supporting Standards

      In compliance with CWA 15580, Digi-Bill™ complies with these supporting standards:


      • Digi-Sign complies with ISO 27001 and has an active Information Security Management System [ISMS]
      • Invoices can be archived from 4 to 11 years, as required
      • Compliance with ETSI TS 101 861 [23] Time stamping profile
      • Compliance with ETSI 102 023 [24] Time stamping profile


CWA 15581

Compliance with EU Directive on eInvoice for EU VAT purposes

PDF [18] In compliance with CWA 15582 Digi-Bill™ complies with 2001/115/EC [6], CWA 15579 [25], CWA 15580 [19] and CWA 15582 [22].

In compliance with CWA 15581, the Digi-Bill™ uses the required advanced electronic signature and timestamp and also ensures that:

  • An explicit agreement is drawn up between the customer and Digi-Sign
  • Digi-Sign is permitted to sign invoices on behalf of the invoice issuer, if this is agreed between the invoice issuer and Digi-Sign


    • References & Supporting Standards

      In compliance with CWA 15581, Digi-Bill™ complies with these supporting standards:


      • Digi-Sign complies with ISO 27001 and has an active Information Security Management System [ISMS]
      • Invoices can be archived from 4 to 11 years, as required
      • Compliance with ETSI TS 101 861 [23] Time stamping profile
      • Compliance with ETSI 102 023 [24] Time stamping profile


CWA 15582

Compliance with EU Directive on eInvoice for EU VAT purposes

PDF [18] In compliance with CWA 15582 Digi-Bill™ complies with 2001/115/EC [6], CWA 15579 [25], CWA 15580 [19] and CWA 15581 [21].

In compliance with CWA 15582, the Digi-Bill™ uses the required advanced electronic signature and timestamp and also ensures that:

  • Compliance with the business processes, the VAT functions, and the service provision for the eInvoicing process are adhered too
  • VAT processes, declaration, verification, verification co-operation and VAT information systems inspection are available
  • The eInvoice is authenticated by Digi-Sign and the integrity of the eInvoice is maintained


    • References & Supporting Standards

      In compliance with CWA 15580, Digi-Bill™ complies with these supporting standards:


      • Digi-Sign complies with ISO 27001 and has an active Information Security Management System [ISMS]
      • Invoices can be archived from 4 to 11 years, as required
      • Compliance with ETSI TS 101 861 [23] Time stamping profile
      • Compliance with ETSI 102 023 [24] Time stamping profile


ETSI Standards

1.ETSI 101 456
2.ETSI 002 176
3.ETSI 102 023
4.ETSI 101 861

ETSI 101 456-1

PDF [1] In response to ETSI 101 456 sub section 7.1 Note 1 and Note 2, the Digi-CAST3™ Team in conjunction with the certified BS 7799 Trust Centre Team will ensure that all documentation, subscriber agreements, Certificate Policy and Certificate Practice Statement [26] are up to date and publicly available.

In response to ETSI 101 456 sub section 7.2.1 and 7.2.2 the key generation is undertaken in a physically secured environment by personnel in trusted roles under dual control. The number of personnel authorized to carry out this function is kept to a minimum and is consistent with the Trust Centre practices.

Both the private signing key is held and the key generation is carried out within the secure cryptographic Eracom Host Orange Hardware Security Module [HSM] device that is certified to FIPS PUB 140-2 level 3 and meets the requirements identified in CEN Workshop Agreement 14167-2 [8] and the keys are not accessible outside the HSM.

The key generation is performed using the RSA algorithm that is a minimum of 1024 bits and is recognized as being fit for the purposes of qualified certificates.

The Digi-CA™ [2] private signing is backed up, stored and recovered only by personnel in trusted roles using dual control in a physically secured environment. The number of personnel authorized to carry out this function are kept to a minimum and be consistent with the Digi-CA’s™ practices and backup copies of the Digi-CA™ private signing keys are subject to a greater level of security controls than the keys currently in use.

In response to ETSI 101 456 sub section 7.2.3 the Digi-CA™ signature verification (public) keys are made available to relying parties by combining the public LDAP directory, Certificate Revokation List and OCSP [16] Service.

In response to ETSI 101 456 sub section 7.2.4 the Digi-CA™ and subject private signing keys are not held in a way which provides a backup decryption capability, allowing authorized entities under certain conditions to decrypt data using information supplied by one or more parties (commonly called key escrow).

In response to ETSI 101 456 sub section 7.2.5 the Digi-CA™ signing key(s) used for generating certificates and/or issuing revocation status information, is not be used for any other purpose and the certificate signing keys are only be used within the physically secure Trust Centre.

In response to ETSI 101 456 sub section 7.2.6 the Digi-CA™ private signing keys are not used beyond the end of their life cycle and all copies of the Digi-CA™ private signing keys are destroyed such that the Private Keys cannot be retrieved; or are retained in a manner such that they are protected against being put back into use.

In response to ETSI 101 456 sub section 7.2.7 the certificate signing cryptographic hardware was not tampered with during shipment and neither was the certificate and revocation status information signing cryptographic hardware. The installation, activation, back-up and recovery of the Digi-CA’s™ signing keys in cryptographic hardware requires simultaneous control of at least of two trusted employees and certificate and revocation status information signing cryptographic hardware is functioning correctly. The Digi-CA™ private signing keys stored on Digi-CA™ cryptographic hardware will be destroyed upon device retirement.

In response to ETSI 101 456 sub section 7.2.9 the secure signature creation device preparation is securely controlled by the service provider and then stored and distributed. Secure signature creation device deactivation and reactivation is securely controlled, where it has associated user activation data. The activation data is securely prepared and distributed separately from the secure signature creation device.

In response to ETSI 101 456 sub section 7.3.1 the Digi-CA™ ensures that subjects are properly identified and authenticated; and that subject certificate requests are complete, accurate and duly authorized. Before entering into a contractual relationship with a subscriber, the Digi-CA™ informs the subscriber of the terms and conditions regarding the use of the certificate. The Digi-CA™ communicates this information through a durable (i.e. with integrity over time) means of communication, which may be transmitted electronically, and in readily understandable language. The service provider verifies by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued. Evidence of the identity is checked against a physical person either directly or indirectly using means which provides equivalent assurance to physical presence and the submitted evidence may be in the form of either paper or electronic documentation. Where the subject is a person, the evidence provided is of full name, date and place of birth, a nationally recognized number, or other attributes that is used to, as far as possible, distinguish the person from others with the same name.

Where the subject is a person who is identified in association with a legal person, or other organizational entity, the evidence provided is of full name, date and place of birth, a nationally recognized identity number, or other attributes of the subject which is used to, as far as possible, distinguish the person from others with the same name; full name and legal status of the associated legal person or other organizational entity, any relevant existing registration information (e.g. company registration) of the associated legal person or other organizational entity and an evidence that the subject is associated with the legal person or other organizational entity. The subscriber provides a physical address, or other attributes, which describe how the subscriber may be contacted. The Digi-CA™ records all the information used to verify the subjects' identity, including any reference number on the documentation used for verification, and any limitations on its validity.

The Digi-CA™ also records the signed agreement with the subscriber including agreement to the subscriber's obligations, agreement to use a SSCD if required, consent to the keeping of a record by the Digi-CA™ of information used in registration, subject device provision, any subsequent revocation, and passing of this information to third parties under the same conditions as required by this policy in the case of the Digi-CA™ terminating its services, whether and under what conditions, the subscriber requires and the subject's consents to the publication of the certificate and confirmation that the information held in the certificate is correct.

The records identified above are retained for at the period of time as indicated to the subscriber and as necessary for the purposes for providing evidence of certification [10] in legal proceedings. If the Digi-CA™ does not generate the subject’s key pair, the certificate request process ensures that the subject has possession of the Private Key associated with the Public Key presented for certification and the CA ensures that the requirements of the national data protection legislation are adhered to (including the use of pseudonyms if applicable) within their registration process.

In response to ETSI 101 456 sub section 7.3.2 the Digi-CA™ checks that the information used to verify the identity and attributes of the subject is still valid and if any of the Digi-CA™ terms and conditions have changed, these shall be communicated to the subscriber and agreed. If any information has changed, this is verified, recorded, agreed to by the subscriber, the Digi-CA™ issues a new certificate using the subject's previously certified Public Key, only if its cryptographic security is still sufficient for the new certificate's intended lifetime and no indications exist that the subject's Private Key is compromised.

In response to ETSI 101 456 sub section 7.3.3 the Digi-CA™ ensures that it issues certificates securely to maintain their authenticity and the procedure of issuing the certificate is securely linked to the associated registration, certificate renewal or rekey, including the provision of any subject generated Public Key. If the Digi-CA™ generated the subject’s key, the procedure of issuing the certificate is securely linked to the generation of the key pair by the Digi-CA™ and the Private Key is securely passed to the registered subscriber or subject. The Digi-CA™ ensures over time the uniqueness of the distinguished name assigned to the subject within the domain of the Digi-CA™. (i.e. over the life time of the Digi-CA™ a distinguished name which has been used in an issued certificate shall never be re-assigned to another entity) and the confidentiality and integrity of registration data shall be protected especially when exchanged with the subscriber, subject or between distributed Digi-CA™ system components. The Digi-CA™ also verifies that registration data is exchanged with recognized registration service providers, whose identity is authenticated, in the event that external registration service providers are used.

In response to ETSI 101 456 sub section 7.3.4 the Digi-CA™ makes available to subscribers and relying parties the terms and conditions regarding the use of the certificate, the qualified certificate policy being applied, including a clear statement as to whether the policy is for certificates issued to the public and whether the policy requires uses of a SSCD, any limitations on its use, the subscriber's obligations including whether the policy requires uses of a SSCD, information on how to validate the certificate including requirements to check the revocation status of the certificate, such that the relying party is considered to "reasonably rely" on the certificate, limitations of liability including the purposes/uses for which the Digi-CA™ accepts (or excludes) liability, the period of time which registration information is retained, the period of time which Digi-CA™ event logs are retained, procedures for complaints and dispute settlement, the applicable legal system; and if the Digi-CA™ has been certified to be conformant with the identified qualified certificate policy, and if so through which scheme. The information identified is available through a durable (i.e. with integrity over time) means of communication, which is transmitted electronically, and in readily understandable language.

In response to ETSI 101 456 sub section 7.3.5 upon generation, the complete and accurate certificate is available to subscriber or subject for whom the certificate is being issued and certificates are available for retrieval in only those cases for which the subject's consent has been obtained. The Digi-CA™ makes available to relying parties the terms and conditions regarding the use of the certificate and the applicable terms and conditions are readily identifiable for a given a certificate. The information identified is available 24 hours per day, 7 days per week. Upon system failure, service or other factors, which are not under the control of the Digi-CA™, the Digi-CA™ makes best endeavours to ensure that this information service is not unavailable for longer than a maximum period of time as denoted in the certification practice statement. The information identified is publicly and internationally available.

In response to ETSI 101 456 sub section 7.3.6 the Digi-CA™ ensures that certificates are revoked in a timely manner based on authorized and validated certificate revocation requests and documents, as part of its certification practice statement the procedures for revocation of certificates including who may submit revocation reports and requests, how they may be submitted, any requirements for subsequent confirmation of revocation reports and requests, whether and for what reasons certificates may be suspended, the mechanism used for distributing revocation status information and the maximum delay between receipt of a revocation request or report and the change to revocation status information being available to all relying parties. This is at most 1 day. Requests and reports relating to revocation (e.g. due to compromise of subject's Private Key, death of the subject, unexpected termination of a subscriber's or subject's agreement or business functions, violation of contractual obligations) are processed on receipt and checked to be from an authorized source. Such reports and requests are confirmed as required under the Digi-CA’s™ practices.

A certificate's revocation status is set to suspended whilst the revocation is being confirmed. The Digi-CA™ ensures that a certificate is not kept suspended for longer than is necessary to confirm its status. The subject, and where applicable the subscriber, of a revoked or suspended certificate, is informed of the change of status of its certificate and once a certificate is definitively revoked (i.e. not suspended) it is not reinstated. Where Certificate Revocation Lists (CRLs) including any variants (e.g. Delta CRLs) are used, these are published at least daily and every CRL is stated a time for next CRL issue and a new CRL may be published before the stated time of the next CRL issue. The certification authority signs the CRL or an authority designated by the Digi-CA™. Revocation management services and Revocation status information are available 24 hours per day, 7 days per week. Upon system failure, service or other factors, which are not under the control of the Digi-CA™, the Digi-CA™ makes best endeavours to ensure that this service is not unavailable for longer than a maximum period of time as denoted in the certification practice statement. The integrity and authenticity of the status information is protected and Revocation status information is publicly and internationally available.

ETSI 101 456-2

PDF [1] In response to ETSI 101 456 sub section 7.4.1 the Digi-CA™ carries out a risk assessment to evaluate business risks and determine the necessary security requirements and operational procedures and retains responsibility for all aspects of the provision of certification [10] services, even if some functions are outsourced to subcontractors. Responsibilities of third parties are clearly defined by the Digi-CA™ [2] and appropriate arrangements made to ensure that third parties are bound to implement any controls required by the Digi-CA™. The Digi-CA™ retains responsibility for the disclosure of relevant practices of all parties. The Digi-CA™ management provides direction on information security through a suitable high level steering forum that is responsible for defining the Digi-CA’s™ information security policy and ensuring publication and communication of the policy to all employees who are impacted by the policy. The information security infrastructure necessary to manage the security within the Digi-CA™ is maintained at all times. The Digi-CA™ management forum approves any changes that will impact on the level of security provided. The security controls and operating procedures for Digi-CA™ facilities, systems and information assets providing the certification services are documented, implemented and maintained and Digi-CA™ ensures that the security of information is maintained when the responsibility for Digi-CA™ functions has been outsourced to another organization or entity.

In response to ETSI 101 456 sub section 7.4.2 the Digi-CA™ maintains an inventory of all information assets and assigns a classification for the protection requirements to those assets consistent with the risk analysis.

In response to ETSI 101 456 sub section 7.4.3 the Digi-CA™ employs personnel, which possess the expert knowledge, experience and qualifications necessary for the offered services and as appropriate to the job function and Security roles and responsibilities, as specified in the Digi-CA’s™ security policy, are documented in job descriptions. Trusted roles, on which the security of the Digi-CA’s™ operation is dependent, are clearly identified. Digi-CA™ personnel (both temporary and permanent) have job descriptions defined from the view point of separation of duties and least privilege, determining position sensitivity based on the duties and access levels, background screening and employee training and awareness. Where appropriate, these differentiate between general functions and Digi-CA™ specific functions. It is recommended that the job descriptions include skills and experience requirements. Personnel exercise administrative and management procedures and processes that are in line with the Digi-CA’s™ information security management procedures. Managerial personnel are employed who possess expertise in the electronic signature technology and familiarity with security procedures for personnel with security responsibilities and experience with information security and risk assessment and all Digi-CA™ personnel in trusted roles are free from conflicting interests that might prejudice the impartiality of the Digi-CA™ operations.

Trusted roles include roles such as Security Officers: Overall responsibility for administering the implementation of the security practices. Additionally approve the generation/revocation/suspension of Certificates; System Administrators: Authorized to install, configure and maintain the Digi-CA™ trustworthy systems for registration, certificate generation, subject device provision and revocation management; System Operators: Responsible for operating the Digi-CA™ trustworthy systems on a day-to-day basis and authorized to perform system backup and recovery; System Auditors: Authorized to view and maintain archives and audit logs of the Digi-CA™ trustworthy systems. Digi-CA™ personnel are formally appointed to trusted roles by senior management responsible for security. The Digi-CA™ do not appoint to trusted roles or management any person who is known to have a conviction for a serious crime or other offence which affects his/her suitability for the position. Personnel do not have access to the trusted functions until any necessary checks are completed.

In response to ETSI 101 456 sub section 7.4.4 physical access to facilities concerned with certificate generation, subject device provision, and revocation management services are limited to properly authorized individuals, Controls are implemented to avoid loss, damage or compromise of assets and interruption to business activities; and Controls are implemented to avoid compromise or theft of information and information processing facilities. Certificate generation, subject device provision and revocation management. The facilities concerned with certificate generation, subject device provision and revocation management are operated in an environment, which physically protects the services from compromise through unauthorized access to systems or data. Physical protection is achieved through the creation of clearly defined security perimeters (i.e. physical barriers) around the certificate generation, subject device provision and revocation management services. Any parts of the premises shared with other organizations are outside this perimeter.

Physical and environmental security controls are implemented to protect the facility housing system resources, the system resources themselves, and the facilities used to support their operation. The Digi-CA’s™ physical and environmental security policy for systems concerned with certificate generation, subject device provision and revocation management services address the physical access control, natural disaster protection, fire safety factors, failure of supporting utilities (e.g. power, telecommunications), structure collapse, plumbing leaks, protection against theft, breaking and entering, and disaster recovery, etc and controls are implemented to protect against equipment, information, media and software relating to the Digi-CA™ services being taken off-site without authorization..

In response to ETSI 101 456 sub section 7.4.5 the integrity of Digi-CA™ systems and information are protected against viruses, malicious and unauthorized software and damage from security incidents and malfunctions are minimized through the use of incident reporting and response procedures. Media used within the Digi-CA™ are securely handled to protect media from damage, theft and unauthorized access. Procedures are established and implemented for all trusted and administrative roles that impact on the provision of certification services and all media are handled securely in accordance with requirements of the information classification scheme. Media containing sensitive data are securely disposed of when no longer required. Capacity demands are monitored and projections of future capacity requirements made to ensure that adequate processing power and storage are available. The Digi-CA™ acts in a timely and coordinated manner in order to respond quickly to incidents and to limit the impact of breaches of security. All incidents are reported as soon as possible after the incident and Digi-CA™ security operations are separated from normal operations.

In response to ETSI 101 456 sub section 7.4.6 Controls (e.g. firewalls) are implemented to protect the Digi-CA’s™ internal network domains from external network domains accessible by third parties and sensitive data are protected when exchanged over networks, which are not secure. The Digi-CA™ ensures effective administration of user (this includes operators, administrators and any users given direct access to the system) access to maintain system security, including user account management, auditing and timely modification or removal of access. The Digi-CA™ ensures access to information and application system functions are restricted in accordance with the access control policy and that the Digi-CA™ system provides sufficient computer security controls for the separation of trusted roles identified in Digi-CA’s™ practices, including the separation of security administrator and operation functions. Particularly, use of system utility programs are restricted and tightly controlled. Digi-CA™ personnel are successfully identified and authenticated before using critical applications related to certificate management and accountable for their activities, for example by retaining event logs. Sensitive data is protected against being revealed through re-used storage objects (e.g. deleted files) being accessible to unauthorized users.

The Digi-CA™ ensures that local network components (e.g. routers) are kept in a physically secure environment and their configurations periodically audited for compliance [10] with the requirements specified by the Digi-CA™. Continuous monitoring and alarm facilities are provided to enable the Digi-CA™ to detect, register and react in a timely manner upon any unauthorized and/or irregular attempts to access its resources. Dissemination application enforces access control on attempts to add or delete certificates and modify other associated information and continuous monitoring and alarm facilities are provided to enable the Digi-CA™ to detect, register and react in a timely manner upon any unauthorized and/or irregular attempts to access its resources. Revocation status application enforces access control on attempts to modify revocation status information.

In response to ETSI 101 456 sub section 7.4.7 an analysis of security requirements are carried out at the design and requirements specification stage of any systems development project undertaken by the Digi-CA™ or on behalf of the Digi-CA™ to ensure that security is built into IT systems. Change control procedures exist for releases, modifications and emergency software fixes for any operational software.

In response to ETSI 101 456 sub section 7.4.8 the Digi-CA’s™ business continuity plan (or disaster recovery plan) addresses the compromise or suspected compromise of a Digi-CA’s™ private signing key as a disaster. In the case of compromise the Digi-CA™ informs all subscribers, relying parties and other CAs with which it has agreements or other form of established relations of the compromise and indicates that certificates and revocation status information issued using this Digi-CA™ key may no longer be valid.

In response to ETSI 101 456 sub section 7.4.9 the Digi-CA™ ensures that potential disruptions to subscribers and relying parties are minimized as a result of the cessation of the Digi-CA’s™ services, and ensure continued maintenance of records required to provide evidence of certification for the purposes of legal proceedings. Before the Digi-CA™ terminates its services, it informs all subscribers, relying parties and other CAs with which it has agreements or other form of established relations and terminates all authorization of subcontractors to act on behalf of the Digi-CA™ in the performance of any functions related to the process of issuing certificates. The Digi-CA™ performs necessary undertakings to transfer obligations for maintaining registration information and event log archives for their respective period of time as indicated to the subscriber and relying party. The Digi-CA™ also destroys, or withdraws from use, its Private Keys. The Digi-CA™ have an arrangement to cover the costs to fulfil these minimum requirements in case the Digi-CA™ becomes bankrupt or for other reasons is unable to cover the costs by itself. The Digi-CA™ states in its practices the provisions made for termination of service such as the notification of affected entities, the transfer of its obligations to other parties and the handling of the revocation status for unexpired certificates that have been issued.

ETSI 101 456-3

PDF [1] In response to ETSI 101 456 sub section 7.4.10 important records are protected from loss, destruction and falsification. Some records may need to be securely retained to meet statutory requirements, as well as to support essential business activities and the Digi-CA™ [2] ensures that the requirements of the European data protection Directive, as implemented through national legislation, are met. Appropriate technical and organizational measures are taken against unauthorized or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data and the information that users contribute to the Digi-CA™ are completely protected from disclosure without the user's agreement, a court order or other legal authorization.

In response to ETSI 101 456 sub section 7.4.11 the Digi-CA™ ensures that all relevant information concerning a qualified certificate is recorded for an appropriate period of time, in particular for the purpose of providing evidence of certification for the purposes of legal proceedings. The confidentiality and integrity of current and archived records concerning qualified certificates are maintained and records concerning qualified certificates are completely and confidentially archived in accordance with disclosed business practices. Records concerning qualified certificates are made available if required for the purposes of providing evidence of certification for the purpose of legal proceedings. The subject, and within the constraints of data protection requirements the subscriber, have access to registration and other information relating to the subject. The precise time of significant Digi-CA™ environmental, key management and certificate management events are recorded and records concerning qualified certificates are held for a period of time as appropriate for providing necessary legal evidence in support of electronic signatures.

The events are logged in a way that they cannot be easily deleted or destroyed (except for transfer to long term media) within the period of time that they are required to be held and the Digi-CA™ documents the specific events and data to be logged. The Digi-CA™ ensures all events relating to registration including requests for certificate re-key or renewal, are logged. The Digi-CA™ ensures that all registration information is recorded such as type of document(s) presented by the applicant to support registration, record of unique identification data, numbers, or a combination thereof (e.g. applicant's drivers license number) of identification documents, if applicable, storage location of copies of applications and identification documents, including the signed subscriber agreement, any specific choices in the subscriber agreement (e.g. consent to publication of certificate), identity of entity accepting the application, method used to validate identification documents, if any and name of receiving Digi-CA™ and/or submitting Registration Authority, if applicable.

The Digi-CA™ ensures that privacy of subject information is maintained. The Digi-CA™ log all events relating to the life cycle of Digi-CA™ keys, the life cycle of certificates, the life cycle of keys managed by the Digi-CA™, including any subject keys generated by the Digi-CA™, the preparation of SSCDs. and ensures that all requests and reports relating to revocation, as well as the resulting action, are logged.

In response to ETSI 101 456 sub section 7.5 policies and procedures under which the Digi-CA™ operates are non-discriminatory. The Digi-CA™ makes its services accessible to all applicants whose activities fall within its declared field of operation. The Digi-CA™ is a legal entity according to national law and has a system or systems for quality and information security management appropriate for the certification services it is providing. The Digi-CA™ has adequate arrangements to cover liabilities arising from its operations and/or activities and financial stability and resources required to operate in conformity with this policy. The Digi-CA™ employs a sufficient number of personnel having the necessary education, training, technical knowledge and experience relating to the type, range and volume of work necessary to provide certification services. The Digi-CA™ has policies and procedures for the resolution of complaints and disputes received from customers or other parties about the provisioning of electronic trust services or any other related matters and a properly documented agreement and contractual relationship in place where the provisioning of services involves subcontracting, outsourcing or other third party arrangements. The parts of the Digi-CA™ concerned with certificate generation and revocation management are independent of other organizations for its decisions relating to the establishing, provisioning and maintaining and suspending of services; in particular its senior executive, senior staff and staff in trusted roles, must be free from any commercial, financial and other pressures which might adversely influence trust in the services it provides. The parts of the Digi-CA™ concerned with certificate generation and revocation management have a documented structure which safeguards impartiality of operations.

In response to ETSI 101 456 sub section 8.1, the Digi-CAST3™ Team will help you ensure that:

    a) There shall be a body (e.g. a policy management authority) with final authority and responsibility for specifying and approving the qualified certificate policy.

    b) A risk assessment is carried out to evaluate business requirements and determine the security requirements to be included in the qualified certificate policy for all the areas identified above.

    c) All the Certificate Policy documents are approved and modified in accordance with a defined review process, including responsibilities for maintaining the qualified certificate policy.

    d) A defined review process exists to ensure that the qualified certificate policies are supported by the Digi-Certificate Practice Statement [26]™.

    e) The Digi-CA™ Xg Trust Centre makes available the qualified certificate policies supported by the Digi-CA™ to all appropriate subscribers and relying parties.

    f) Revisions to qualified certificate policies supported by the Digi-CA™ are made available to subscribers and relying parties.

    g) The qualified certificate policy incorporates all the requirements of Clauses 6 and in particular:

    h) That the Digi-CA™ Xg Trust Centre is responsible for conformance with the procedures prescribed in this policy, even when the CA functionality is undertaken by sub-contractors.

    i) The CA shall provide all its certification services consistent with its certification practice statement.

    j) That the subscriber submits accurate and complete information in accordance with the requirements of the ETSI 101 456 policy, particularly with regards to registration and that the subscriber only uses the key pair for electronic signatures in accordance with any other limitations notified to the subscriber. That the subscriber exercises reasonable care to avoid unauthorized use of the subject's Private Key and if they participate in generating these keys using the Process Method that the algorithm used is recognized as being fit for the purposes of qualified electronic signatures and that the key length and algorithm are recognized as being fit for the purposes of qualified electronic signatures.

    k) The Digi-CA™ can show that only the subject holds the Private Key once delivered to the subject and that if the Certificate Policy requires use of an SSCD (i.e. QCP public + SSCD), the Digi-CA™ will only use the certificate with electronic signatures created using such a device.

    l) If the Digi-CA™ is not required to issue qualified certificates and if the certificate is issued by the CA under the Certificate Policy for QCP public + SSCD and the subject's keys are generated under control of the subscriber, the Digi-CA™ will generate the subject's keys within the SSCD to be used for signing.

    m) The Digi-CA™ Administrator will also ensure that subscribers will notify them without any reasonable delay, if any of the following occur up to the end of the validity period indicated in the certificate:

    n) the subject's Private Key has been lost, stolen, potentially compromised; or

    o) control over the subjects Private Key has been lost due compromise of activation data (e.g. PIN code) or other reasons; and/or

    p) inaccuracy or changes to the certificate content, as notified to the subscriber.

    q) and should any of the above occur, the use of the subject's Private Key is immediately and permanently discontinued.

    r) the Digi-CA™ unique OID is obtained for the Certificate Policy of the form required in ITU-T Recommendation X.509 [3].
    In response to ETSI 101 456 sub section 8.3, the Digi-CAST3™ will advise whether your Certificate Policy requires the use of SSCD and the ways in which the specific policy adds to or further constrains the requirements of the qualified certificate policy as defined in ETSI 101 456.

In response to ETSI 101 456 sub section 8.3, the Digi-CAST3™ will ensure you only claim conformance to the standard and the applicable qualified certificate policy by ensuring you adhere to the standard as a whole.

ETSI 002 176

PDF [1] Digi-CA™ complies with this standard by using defined Algorithms and Parameters for Secure Electronic Signatures, that are accepted by this standard, namely:


            • Cryptographic hash function used: SHA1
            • Padding function used: emsa-pkcs1-v1_5
            • Signature algorithm used: rsa
            • Key generation algorithm: rsa (rsagen1)
            • Random number generation: true random number generation (FIPS 140-2 Level 3
            • HSM hardware) or pseudo-random generation (PRNG)


ETSI 102 023

PDF [1] By virtue of the fact that the Digi-CAST3™ Team will help you select the correct Time Stamping [12] Policy and TimStamping Authority Practice Statements so that they comply with this standard, this means that the subsequent use of the Digi-CA™ [2] in accordance with these document means that it is compliant with this standard.

ETSI 101 861

PDF [1] The Time Stamping [12] Policy Server used in conjunction with the Digi-CA™ [2]:


            • accepts client requests in format accepted by this standard
            • accepts all request parameters enforced by this standard
            • recognizes and supports the following hashing algorithms: SHA-1, MD5, RIPEMD-160
            • supports signature algorithm: SHA1 with RSA
            • supports key length: 1024-2048
            • supports Time Stamp Protocol via HTTP



And in so doing makes Digi-CA™ compliant with this standard.

IETF RFC Standards

PDF [1]
7.14 IETF RFC 2527
7.15 IETF RFC 3647

IETF RFC 2527

PDF [1] Complying with this standard means the Digi-Certificate Practice Statement [26]™ documentation is written according to the guidelines set out in this document and Digi-CAST™ will ensure that your CPS meets these guidelines.

IETF RFC 3647

PDF [1] Complying with this standard means the Certificate Policy documentation is written according to the guidelines set out in this document and Digi-CAST™ will ensure that your CPS meets these guidelines.

ISO 27001

ISO 27001 is the Certification Standard from the International Standards Oganization [ISO] Certification for Information Security Management System [ISMS]. It is based on the internationally accredited British Standard BS7799 that has been in existence for more than a decade and was significantly revised and improved in May 1999.

All organisations trying to follow best practice to design, deploy, run and support ICT security systems should consider an ISMS. ISMS are frameworks with a systematic approach to managing sensitive company information so that it remains secure. It encompasses premises, people, processes and IT systems.

ISO/IEC 27001:2005 is the latest international standard Specification for an ISMS. In October 2005, BS 7799 part 2 was adopted by ISO, its name was changed to be officially released as the new international standard ISO/IEC 27001:2005. ISO 27001 is essentially a direct replacement for BS 7799 part 2. It includes a summary of ISO 27001:2005 controls as an appendix.

The standard covers the following topics:

  • Security policy
  • Organization of assets and resources
  • Asset classification and control
  • Personnel security
  • Physical and environmental security
  • Communications and operations management
  • Access control - To control access to information
  • Systems development and maintenance
  • Business continuity management
  • Compliance

It is important to note that not all departments of the organisation must apply for the standard which means that organisation XYZ may be certified for department 1 but not for department 2. When applying for the standard, applicants are asked to confirm where the standard should be applicable for their organisation in the “Statements of Applicability”.

To implement the ISMS according to ISO 27001 in your organisation, consult the Digi-CAST™ [5] Team that use a methodology specifically for ISO 27001 that can expedite your ISO 27001 Certification considerably.

Implementing ISO 27001

PDF [27] Digi-CAST™ [9] is the system used to implement all Certificate Authority systems. Digi-CAST3™ is the methodology used to implement the compliance strategy for ISO 27001 [28].

1. Scope of the ISMS

PDF [29] This ISMS is specific only to the three Certificate Authority [CA] rooms in Isa Town, the five Registration Authority Control Centre operator desks located on the ground floor of the National ID card issuing centre in Isa Town and the two Public Servers located in Juffair, in the Kingdom of Bahrain. The ISMS does not extend beyond these two geographicaal locations and the personnel that make up the operational and management team for these areas. It should also be noted that the Key Ceremony(s) that occurs is outside the physical environment and is not included in the ISMS, however, detailed scripts, explanations and security documentation from each Key Ceremony will be introduced into the ISMS as required.

The Information Security Management System covers all activities within the PKI [30] infrastructure in Juffair and ISA Town including related infrastructure key components such as Digi-CA and associated HSM. It relates to all assets, software and infrastructure used for storing, handling, processing and distributing digital certificates to Bahrain citizens.

1.2 Definitions

Where terms which are used in ISO27001:2005 are used here, the definitions provided in clause 3 of that standard are applied. Where terms are defined in ISO17799:2005 but not in ISO27001:2005, the ISO17799:2005 definitions are applied here.

1.3 ISMS

In particular, the ISMS is defined as the part (which includes organisational structure, policies, planning activities, plans, responsibilities, working practices, procedures, processes and resources) of the Organisation’s overall management system which, based on a business risk approach, enables management to establish, implement, operate, monitor, review, maintain and improve information security within the Organisation.

A current version of this document is available to PKI staff members of staff and is available on request from the Information Security Manager.

This procedure was approved by the Director General of IT and the Information Security Manager on 08 November, 2007 and is issued on a version controlled basis under his/her signature

Adlin Hisyamuddin Shaikh Salman Mohammed Al-Khalifa
Information Security Manager Director General of IT

____________________________ _______________________________

On:

08 November, 2007 08 November, 2007
____________________________ _______________________________

Change history

Issue 1 7 November, 2007 Initial issue

2. Documentation

2.1 Constituents

PDF [29] The Organisation’s ISMS documentation consists of:

    2.1.1 The scope statement (Section 1 above), information security policy (Section 5 below), and Statement of Applicability, all of which are included in this manual. This manual is, together with any separately published policies, the Organisation’s Tier 1 ISMS documentation. The control objectives described in this manual are achieved by controls that include policies (which provide board approved guidelines on specific control areas) and procedures. These policies are either included in, or referenced from, this manual; [ISO27001 4.3.1a, b, g and i]

    2.1.2 The separate, version controlled risk assessment report and risk treatment plan, whose preparation follows the methodology described in Section 4 of this manual; [ISO27001 4.3.1c, d and f]

    2.1.3 Records of how the Organisation applied (and continues to apply) the PLAN-DO-CHECK-ACT process, which is described in Section 3 of this manual, in the planning, implementation and maintenance of its ISMS; [ISO27001 4.3.3]

    2.1.4 Those procedures, which describe how the policies are implemented, and which are identified in this manual but are separate from it, are Tier 2 documents; [ISO27001 4.3.1e]

    2.1.5 Work Instructions and Operations Work Instructions, which set out specific requirements for the performance or execution of specific tasks, including for the measurement of the effectiveness of the controls, in the Organisation generally and in the [IT operations department] specifically, and which are identified in procedures, and similar documents, such as User Agreements and job descriptions, are Tier 3 documentation;

    2.1.6 Records of the Organisation’s control of its information security processes, including details of audits, information security incidents and management reviews gathered during the CHECK phase, described in 3.3 below, are the fourth tier of the Organisation’s ISMS documentation. [ISO27001 4.3.1h]

2.2 Authorisation Levels

    2.2.1 The organization has clearly defined authorization levels that cannot be delegated.

    2.2.2 The board of directors has ultimate authority over the information security policy and ISMS and approves and authorizes all changes to the information security policy, the Statement of Applicability, the information security manual and any separate policy statements (tier 1 documents).

    2.2.3 The Director General of IT (see sub section 6.1.3.2 [31]) has lead executive authority for information security and works with the Information Security Manager to approve, authorize and issue all tier 2 documents.

    2.2.4 The Information Security Manager and the Director General of IT approve and authorize tier 3 documents owned by individuals or entities in their areas of responsibility. Any information security documents personally owned by any member of the Trust Centre Team have to be approved and authorized by the Director General of IT.

    2.2.5 Owners of information assets (see sub section 7.1.2 [31] of the Manual) are responsible for the security classification of their asset(s), the day-to-day protection of their asset(s) and for the day-to-day operation of related security processes. The responsibility for carrying out these processes or associated task(s) can be delegated to anyone within the Owner’s area of responsibility, provided that:

    a) The individual has the necessary skill, competence and resources to carry out the processes or task(s) and

    b) The Owner retains accountability for ensuring that the process or task is carried out correctly.

    2.2.6 Access rights are specified in sub section 11.1 below. Access rights are personal, are set out in individual User Agreements (see sub sections 11.2 [32] and 11.3 [32]) and cannot be delegated.

    2.2.7 The authorization procedure for new information processing facilities is set out in DOC 6.4. wherever this type of reference occurs, can you specifically write [ISO27001 DOC 6.4] so the CIO knows where to find this.

2.3 The Organisation’s ISMS documentation is protected and controlled. There is a documented procedure (DOC ISMS 1) which takes 2.2 above into account and defines the management actions for document control. [ISO27001 4.3.2]

2.4 The Organisation has a documented procedure which defines the controls for identification, storage, protection, retrieval, retention time and disposal of records. [ISO27001 4.3.3] Documents are available to those who need and are authorised to access them in line with these retention requirements.

Adlin Hisyamuddin Shaikh Salman Mohammed Al-Khalifa
Information Security Manager Director General of IT

____________________________ _______________________________

On:

08 November, 2007 08 November, 2007
____________________________ _______________________________

Change history

Issue 1 08 November, 2007 Initial issue

3. PLAN-DO-CHECK-ACT

PDF [29] 3.1 The PLAN Phase – Establish the ISMS

    3.1 a) The Organisation defined the scope of the ISMS in Section 1.

    3.1 b) The Organisation has defined its information security policy, which is set out in Section 5, to apply throughout the Organisation as defined in the scope (Section 1 above). The policy includes:

      3.1 b1) A framework for setting objectives for the ISMS in order to preserve its competitive edge, cash-flow and commercial interests as applicable and an enabling mechanism for information sharing, for electronic operations and an overall sense of direction will continue to be aligned with Organizational goals and all personnel and principles involved with the CIO Trust Centre are committed to preserving the confidentiality, integrity and availability of all the physical and electronic information assets for action with regard to information security; [ISO27001 4.2.1 b1)].

      3.1 b2) The requirement for “legal, regulatory and contractual” in accordance with the standard is adequately addressed by the Civil Service Bureau; [ISO27001 4.2.1 b2)]

      3.1 b3) The strategic organizational and risk management context for the establishment and maintenance of the ISMS (“the Organization’s current strategic business plan and risk management framework provide the context for identifying, assessing, evaluating and controlling information-related risks”); [ISO27001 4.2.1b3)] and

      3.1 b4) Reference to a systematic approach to risk assessment, the risk management framework (4.2 below) in which the criteria for risk evaluation are described and the structure of the risk assessment is defined (4.4 below). [ISO27001 4.2.1 b4)]

      3.1 b5) The policy, and this manual, have been approved by The Director General of IT and the President of the CIO. [ISO27001 4.2.1 b5)]

    3.1 c) The Organization has identified a suitable, systematic approach to and framework for risk assessment that produces comparable and reproducible results and that is appropriate for its business, legal, regulatory and contractual requirements, and this is described in Section 4 below. [ISO27001 4.2.1c)]

    3.1 d) Identification of risks is carried out in line with the process set out in Section 4 below. [ISO27001 4.2.1d)]

    3.1 e) Assessment (the analysis and evaluation) of risks is carried out in line with the process set out in Section 4 below. [ISO27001 4.2.1e)]

    3.1 f) Options for risk treatment are identified and evaluated in line with the process set out in Section 4 below. [ISO27001 4.2.1f)]

    3.1 g) Control objectives and controls are selected from [Annex A of ISO27001 :2005] to meet the criteria and requirements of the risk management framework, take into account the risk acceptance criteria (Section 4, below) and current legal, regulatory and contractual requirements and are contained in the Statement of Applicability [ISO27001 4.2.1g)], together with details of the controls currently implemented [ISO27001 4.2.1.j.2].

    3.1 h) The Statement of Applicability is contained in Sections 5 - 15 of this manual and in approving this manual management accept the residual risks (see sub section 4.6.3 [32] also). [ISO27001 4.2.1h)]

    3.1 i) Management authorises the implementation of the ISMS and any changes to this manual [and approve the residual risks] [ISO27001 4.2.1i)]

3.2 The DO Phase – Implement & Operate the ISMS

    3.2 a) The Organisation’s risk treatment plan (DOC 4.1 [32]) reflects the decisions made in the PLAN phase, and identifies the management action, responsibilities and priorities for managing the identified information security risks. [ISO27001 4.2.2a)]

    3.2 b) Appropriate funding and resources are, as described in the risk treatment plan, allocated to its implementation. [ISO27001 4.2.2b)]

    3.2 c) The selected controls are implemented (and their implementation is co-ordinated across the Organisation) to meet the identified control objectives. [ISO27001 4.2.2c)]

    3.2 d) The Organisation has defined how it measures the effectiveness of its controls and has specified how to use these measurements to improve control effectiveness to produce comparable and reproducible results, and this is set out in DOC 3.1. [ISO27001 4.2.2d]

    3.2 e) Training and awareness programmes are implemented as required in the risk treatment plan. [ISO27001 4.2.2e)]

    3.2 f) The operational management procedures and work instructions required in this policy are implemented. [ISO27001 4.2.2f)]

    3.2 g) The Organisation has committed specific resources to the effective management of the ISMS, including the nomination of Mubarak Abdulla Alhiddi as the Chief Security Officer [CSO] for the Trust Centre and Adlin Hisyamuddin as the Information Security Manager; and the recruitment of additional technical staff, inclusion of information security in all jobs relating to the management, maintenance and operations of a National Trust Centre for the issuing of Digital Certificate [14] as well as investing in information security products and services as required by the risk treatment plan (DOC 4.1 [32]). [ISO27001 4.2.2g)]

    3.2 h) The Organisation has implemented monitoring procedures and controls as required by control objectives 10.10 and 13.1 below. [ISO27001 4.2.2h)]

3.3 The CHECK Phase – Monitor and Review the ISMS

    3.3 a) The controls implemented to meet control objectives 10.10 and 13.1 below are operated to [promptly detect processing errors, and] detect security events, to identify failed and successful security breaches and incidents, enable management to assess whether security activities are performed in line with the criteria set for them, and take action to resolve any breach of security in a way that reflects the Organisation’s priorities. Also see sub section 3.4 below. [ISO27001 4.2.3a)]

    3.3 b) The Organisation and its management regularly review the effectiveness of the ISMS, in line with the policy and procedures identified in control 5.1.2 below, seek to continuously improve the effectiveness of the ISMS through analysing audit results, and monitoring events and activity, all in the context of the business goals and risk treatment plan, and at least once a year. [ISO27001 4.2.3b) and e), 7.1, 8.1]
    3.3 c) The Organisation measures the effectiveness of controls, as set out in DOC 3.1, to verify that security requirements have been met. [ISO27001 4.2.3c)]

    3.3 d) At planned intervals as well as whenever there are significant changes in the Organisation, technology, business objectives and processes, identified threats or external (legal, regulatory, social) changes, the Organisation reviews those aspects of its risk assessment and risk treatment plan, including levels of residual risk and acceptable risk (taking into account changes in the effectiveness of controls), that are affected by the changes, or carries out additional assessments of specific risks in relation to new technologies, and system or any other changes that affect Organisational information or information assets. [ISO27001 4.2.3d)]

    3.3 e) Management ensures that the Organisation carries out regular internal ISMS and other audits, as required in controls 6.1.8, 15.2 and 15.3 below, and the results of these audits inform the reviews identified in 3.3b) above. [ISO27001 5.1.g & 4.2.3e)]

    3.3 f) Actions or events that could impact the effectiveness of the ISMS are recorded in line with sub sections 10.10 and 13 below [ISO27001 4.2.3f & g)] and are reviewed at management review.

    3.3 g) The risk treatment plan (DOC 4.1 [32]) is updated to take into account the findings of monitoring and reviewing activities.
    3.3 The ACT Phase – Maintain & Improve the ISMS

3.4 Opportunities for The ISMS

    3.4 a)Where improvement opportunities for the ISMS are identified during the CHECK phase (see 3.3b) and d) above), they are implemented if they meet the criteria of the risk treatment plan. [ISO27001 4.2.4a)]

    3.4 b) The Organisation has documented procedures for corrective and preventative action throughout the ISMS (including but not limited to those in sections 10.2.2, 13, 14.1.5 and 15.2 of this manual; sub section 6.1.7 enables it to learn from the experiences of other organisations and control 13.2.2 ensures it learns from its own experiences) and these include evaluating the need for action to prevent the occurrence of non-conformities. [ISO27001 4.2.4b] All controls have an element of preventative action involved in them.

    3.4 c) The results of reviews are communicated to everyone involved via email and action delegated to the appropriate people, in line with 6.1.3 and 13.2.1 below. [ISO27001 4.2.4c)]

    3.4 d) The implemented improvements are subject to monitoring and audit (see 15 [32]) to ensure that their intended objectives have been achieved. [ISO27001 4.2.4 d)]

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

4. Risk Management Framework


4.1 Risk Approach

PDF [29] The Organisation’s approach to risk, which has been specifically approved and authorised by management, is contained in the risk management framework, which it applies to its overall strategic planning process. The risk management framework is designed to identify and assess risks (including information security risk) in the business plan, to identify and evaluate options for the treatment of those risks, and to select control objectives and controls that will reduce those risks to acceptable levels within the context of the business plan, operational requirements, constraints and objectives and national and international legislation and regulation. [ISO17799 4.1 and 4.2]

4.2 Risk Framework

    4.2.1 Choice of risk assessment tool/methodology

    CIO has decided not to use an automated tool to perform risk assessments. Instead it has sought advice from external security consultants VigiTrust to set out the initial to procedures and documentation and in conjunction and co-operation with the Digi-CAST3™ Team, has been trained on the use of this manual and the implementation of the procedures necessary to produce a number of methodologies to perform risk assessment on a regular basis

    4.2.2 Requirements

    Risk assessments projects need to be carried out regularly and need to help CIO identify the threat landscape, vulnerabilities and threat levels associated to each vulnerability against each of its tangible and intangible assets.

    4.2.3 Selection Criteria

    CIO opted to work with Digi-Sign because of its knowledge of Certificate Authority [CA [4]] and Public Key Infrastructures [PKI [30]] and with VigiTrust because of their in the filed of risk assessment for particularly sensitive information and projects related to the security of sensitive assets.

    4.2.4 Tools/Methodologies Considered

    CIO considered tools such as RA2 or equivalent on the market. However these tools require a deep understanding of the current security threat landscape and are only extremely effective for security professionals.

    It was therefore decided to work with security consultants who had their own methodologies backed by a proven track record of helping blue chip organizations to meet security best practice guidelines.

    4.2.5 How the Tool/ Methodology was Selected
    Some initial research was conducted by CIO as to whether an automated tool would be appropriate to perform the risk assessment tasks related to this project. It was very quickly identified that consultants would be required in order to engage with CIO and conduct risks assessments. After a full tendering process in accordance with the laws of the Kingdom of Bahrain and a lengthy and careful consideration process, Batelco and Digi-Sign were selected to provide this service to the CIO in co-operation with Digi-Sign’s ISO consultancy partner VigiTrust.

    4.2.6 How the Methodology Works

    The chosen methodology is based on benchmarking vulnerabilities and threats to each assets against a risk matrix. The matrix consists in evaluation of the asset in terms of importance to CIO, assigning a probability of likelihood for each threat and determining an absolute impact for the threat. The risk is calculated as follows:

    Risk (aka “Absolute risk”) = Probability of Threat * Absolute Impact of Threat

    The information below details all of the elements of this risk calculation model:

    Evaluation of Assets

    The operation owner defines the value of each asset detected depending on his perception of impact on operations) or on users in general in case of loss, theft, inaccessibility, deterioration / corruption or any other security violations. Perceived value is ranked as follows:

    Unimportant (0) Damage on the asset never affects the data system

    Not very important (1) Damage on the asset has very little impact on the data system. The data system keeps operating. Damage on it does not tarnish the company name.

    Medium (2) Damage on the asset affects the data system. The data system keeps operating but the asset in question must be replaced. Damage thereon can affect the company name negatively to a somewhat noticeable extent.

    Important (3) Damage on the asset has major impact on the data system. The data system is only half operational in that it may not be fully accessible or its integrity might have been somewhat compromised. The asset in question must be replaced. Damage thereon affects the company name adversely.

    Very important (4) The asset plays a major part for the operation of the data system. Damage on the asset has a huge impact on the operability of the data system. Only parts of the data system remain useable. Damage thereon has substantial adverse impact on the company name.

    Extremely important (5) The asset is essential for the operation of the data system. Damage on the asset directly influences the data system. The data system is out of operation. Damage thereof has very adverse impact on the company name.

    At this stage Potential vulnerabilities are listed for each asset. Vulnerabilities are the weaknesses identified for assets. Potential threats are listed for each asset. Threats are potential tools by which vulnerabilities can be misused or exploited.

    Important Note: The value as determined by the above procedure is entered in the “Critical” column Risk Treatment Plan file that accompanies this document and is referenced “Digi-CAST Asset List & Risk Treatment Issue 001-071107.xls”.
    Threat Probability Values

    Negligible (0) Not likely to happen.

    Very low (1) Twice or three times in a period of 5 years.

    Low (2) May happen once a year or a shorter period of time.

    Medium (3) May happen every six months or within a period of time between one to 6 months.

    High (4) May happen once a month or within a period of time between 2 days to one month.

    Very high (5) May happen once a day.

    Extremely High (6) May happen multiple times a day.

    Threat Impact Values

    Unimportant (0) The threat has no impact on the asset.

    Small (1) The threat has little impact on the asset. There is no need to repair or re-configure the asset.

    Important (2) Although the impact by the threat is minor and is only reported by a few persons or organizations, the threat can still have concrete damage. Corrective action involving time, effort and financial input may have to be implemented to make up for the damage and eradicate the issues.

    Detrimental (3) The Threat can damage the reputation of asset and system operators. Significant spending may be necessary to repair the damage and eradicate the issues.

    Serious (4) The Threat inflicts substantial damage on the asset and/or many staff members and the organization itself may be significantly impacted by the damage. Large scale restructuring may be necessary in the damaged system. Corrective action needs to be taken to eradicate the issues.

    Very serious (5) Threats causes the asset to be out of operation indefinitely. It requires the system to be re-designed and re-structured totally. Corrective action needs to be taken to eradicate the issues.
    The information pertaining to absolute risks requires the use of the values detailed above according to the formula, Absolute Risk = Threat Probability Value * Threat Impact Value.

    So by determining the “Threat Probability Value” (i.e. 1 – 6) using the horizontal part of the following Risk Calculation Table and then searching down the vertical column for the “Threat Impact Value”, the “Absolute Risk Value” can be calculated.

    Important Note: All three values are entered in the Risk Treatment Plan file that accompanies this document and is referenced “Digi-CAST Asset List & Risk Treatment Issue 001-071107.xls”.

    Every time an asset is added or removed from the Trust Centre, this Digi-CAST™ [9] Manual and the “Digi-CAST Asset List & Risk Treatment” must be updated and must be signed by the Information Security Manual.

    In addition, the new Issue must be circulated to all members of the Trust Centre Team and Trust Centre Management. And this is the responsibility of the Information Security Manager.


    Risk Calculation Table


    Probability of the Threat to
    Happen
    Unimportant
    (0)
    Minor (1) Important (2) Detrimental (3) Serious (4) Very serious
    (5)
    Negligible (0) None (0) None (0) None (0) None (0) None (0) None (0)
    Very low (1) None (0) Low (1) Low (2) Low (3) Medium (4) Medium (5)
    Low (2) None (0) Low (2) Medium (4) Medium (6) High (8) High (10)
    Medium (3) None (0) Low (3) Medium (6) High (9) High (9) Critical (15)
    High (4) None (0) Medium (4) High (8) High (12) Critical (16) Very High (20)
    Very High (5) None (0) Medium (5) High (10) Critical (15) Very High (20) Very High (25)
    Extremely High (6) None (0) Medium (6) High (12) Critical (18) Very High (24) Very High (30)



    Absolute Risk Table

     


    Absolute Risk

    Risk
    Score

    Multiplication
    Values


    Corresponding to
    the Risk Score

    None 0 0
    Low 1 1,2,3
    Medium 2 4,5,6
    High 3 8,9,10,12
    Critical 4 15,16,18
    Very high 5 20,24,25,30

    Actual Risk Value is calculated by using the following final formula:

    1. Absolute Risk = Probability of the Threat * Absolute Impact of the Threat

    2. Absolute Risk Score  Simplified Absolute Risk Score (Table 4)

    3. Actual Risk Value = New Absolute Risk Score * Asset Value Identification of Targets, Controls and Counter Measures and Management of Risks
    3–Step Absolute Risk Calculation

    Step 1

    Take into consideration the impact an event using the “Threat Impact Values” scale above (0 - 5).

    Step 2

    Then consider the likelihood it could happen using the “Threat Possibility Values” scale above (0 - 6).

    Step 3

    Then use the table, which gives you the risk for the RTP (it is a basic multiplier). The value you get will appear on the “Absolute Risk Table” and this enables you to label the Risk appropriately.

    Example

    Rack server:

    The Rack could be physically damaged or it could collapse resulting in machines having to be powered off before being moved - results in disruption to services.

    Probability of that happening is low (2) however impact of the issue, if it did happen, is high (4) as it would seriously disrupt services. Therefore the Absolute Risk Value is 4 x 2 = 8. The Absolute Risk (8) is then entered in the Absolute Risk column of the Digi-CAST Asset List & Risk Treatment.

    In Summary

    Low Absolute Risk Value is typically low to high impact with little probability of occurrence (or vice versa).

    High Absolute Risk Value is typically high impact and high probability (unusual and rare, but may occur).

    Medium Absolute Risk Value is more complicated and requires careful attention as it suggests that the impact would be medium to high and so is the probability. This is where indicating actual controls in place will ensure that a proper risk assessment has been conducted.

    Consider the asset and carefully consider the likelihood of the potential threat happening. Should it happen, what impact would have it have on the CIO Trust Centre if it did happen and then using the above system assign figures and calculate the Absolute Risk Value.

    4.2.7 Training requirements
    The CIO Trust Centre staff must understand the scoring mechanism and regular training should be provided by the Information Security Manager to all the members of the Trust Centre Team. In addition ongoing security awareness through training, reference manual, demonstration and incident reporting, resolution and documentation is provided in order for Trust Centre Team to keep abreast of the latest threats in order to be able to continually assess risks and take pre-emptive action.


4.3 Information Security Risk Management

    4.3.1 The Organisation has established and maintains its ISMS, and identifies and assesses information related risks, and evaluates options for their treatment, within the context of the risk management framework described in DOC 4.3 and performs risk assessments in line with DOC 4.4, using the tool selected following the procedure documented in DOC 4.2.

    4.3.2 Control objectives and controls are selected from Annex A of [ISO27001/ISO17799:2005] on the basis of the conclusions to step 4.3.1. Additional control objectives and controls are, not required from other sources other than ISO27001. All control objectives and controls are documented in the Statement of Applicability, which is set out in Sections 5 to 15 of this manual.

    4.3.3 A consolidated; corporate level risk treatment plan (DOC 4.1) is formulated in order to implement the selected controls.

    4.3.4 The implementation is reviewed for effectiveness and, where possible, improvements are identified and these, within the context of the overall ISMS, are implemented, using a PDCA process.

    4.3.5 This process is followed irrespective of whether a single risk is being considered, or multiple risks.


4.4 Risk Assessment Tool & Methodology
The Organisation’s method for risk assessment is to use risk assessment tool in this Digi-CAST™ [9] Manual and uses the procedure as set out below. This tool and methodology is suitable for the scope of the Organisation’s ISMS (Section 1), the business objectives (3.1b1 above), the security, contractual, legal and regulatory requirements (3.1b2) above and risk management framework that were identified earlier. The selection criteria are set out in DOC 4.2. [ISO27001 4.2.1c] and the risk assessment procedure itself is carried out as described in DOC 4.4.

    4.4.1 Scope

    This method of risk assessment is applied throughout the Organization in respect of information risks.

    4.4.2 Responsibilities

    The Information Security Manager is responsible for carrying out risk assessments wherever they are required by the ISMS.

    Procedure

    4.4.3 Identity of Risks

      4.4.3.1 The assets that are within the scope of the ISMS are identified and listed in line with the requirements of DOC 7.1 [32] (asset inventory), The business, legal and contractual requirements and asset values are established at the same time and in line with DOC 7.1. [32]

      4.4.3.2 When new information assets (in the broad sense of DOC 7.1 [32]) are acquired, or existing assets in any way changed, those assets are added to the inventory and are treated in line with the requirements below.

      4.4.3.3 The threats to each of those assets are identified in process 4.1. For each asset within the ISMS, all applicable threats are selected from the list of example threats. The Information Security Manager is responsible for ensuring that the list of threats is adequate for the ISMS.

      4.4.3.4 The vulnerabilities that might be exploited by each of these threats are identified once each threat has been identified and listed.

      4.4.3.5 Where new vulnerabilities or weaknesses are identified (for e.g., through the information security event reporting procedure in DOC 13.1 [32]), the risk database is updated and, if appropriate, the risk assessment procedure set out here is repeated and any changed controls implemented.

      4.4.3.6 Risk of exposure is assessed using process 4.2. For each threat/vulnerability combination, the threat likelihood and vulnerability level are calculated and a brief explanation may added for further clarity. Finally, at this stage, the security properties that are affected by this exposure risk are identified.

    4.4.4 Assess the Risks

      4.4.4.1The Information Security Manager will carry out the ISMS risk assessment on an ongoing basis. Once all the preceding steps have been completed and approved, the risks for each of the assets will be calculated within the ISMS.

      4.4.4.2Within this process, a risk name is allocated to each threat/vulnerability combination and is placed within the appropriate risk category available.

    4.4.5 Identify & Evaluate Options for the Treatment of Risks

      4.4.5.1The appropriate risk treatment decision is made for each identified risk for each asset within the ISMS. The risk treatment decision is made in line with the requirements of DOC 4.3.

      4.4.5.2For each of the risk treatment decisions, document the reasons for the decision in the appropriate tab, together with specific actions to be taken (usually, apply appropriate controls from Annex A of ISO 27001)

    4.4.6 Select Control Objectives & Controls for Treatment of Risks

      4.4.6.1Appropriate control objectives and controls are selected from Annex A of BS7799-2:2005/ISO17799.

      4.4.6.2 These control objectives and controls are then manually summarized into the Statement of Applicability.

      4.4.6.3. Provide justifications for all selected controls and for non-selected controls. Once this is complete for all controls.

      4.4.6.4The complete Statement of Applicability is printed out, a signed copy retained by the Information Security Manager and decision for each control objective and control is manually transferred to the ISMS Manual, which describes how each control is actually implemented.

    4.4.7 Implementation

    Controls are implemented according to relevant associated processes and OWIs pertaining to each threat.

    The Information Security Manager is the owner of this document and is responsible for ensuring that this procedure is reviewed in line with the review requirements of the ISMS.

    A current version of this document is available to the Trust Centre team members on request.

    This procedure was approved by the Director General of IT and the President of the CIO on 08 November 2007 and is issued on a version-controlled basis under their signatures.

4.5 Systematic approach to risk assessment
The Organisation has a documented approach (framework in DOC 4.3, tool in DOC 4.2 and procedure/methodology in DOC 4.4) to risk assessment.

4.6 Prepare a Statement of Applicability

    4.6.1 The control objectives and controls selected in line with clause 4.5, and as a result of carrying out the procedure identified in DOC 4.4, are documented in a Statement of Applicability, which forms Sections 5 to 15 of this Manual.

    4.6.2 Any controls or control objectives in Annex A of [ISO27001/ISO17799:2005] that are excluded are documented, together with the justification for their exclusion; any additional controls or control objectives that may be required are also documented in the Statement of Applicability.

    4.6.3 The remaining residual risks are highlighted in the risk treatment plan (DOC 4.1) as required by DOC 4.3, and board authorisation is obtained for implementation of the ISMS.

    4.6.4 Any changes to the risk treatment plan (DOC 4.1), which lead to a change in the ISMS, are subject to authorisation by the board.

    Shaikh Salman Mohammed Al-Khalifa Mohammed Al-Amer
    Director General of IT President of CIO

    ____________________________ _______________________________

    On:

    08 November, 2007 08 November, 2007
    ____________________________ _______________________________
    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue


5. Information Security Policy

5 PDF [29] Information Security Policy
Control objective: The organization provides management direction and support for information security in accordance with business requirements and relevant laws and regulations of the Kingdom of Bahrain.

    5.1.1 Information security policy document

    The management team and the board of directors have approved and authorized an information security policy for the Organisation. This policy is set out below and is authorized for separate distribution under the President of CIO’s signature, with the reference DOC 5.1. A current version of this document is available to all staff and contractors, and to external parties [when signing supply contracts]. The development of the information security policy is carried out under the PDCA process described in Section 3 of the Information Security Manual.

    INFORMATION SECURITY POLICY

    The Board and management of The Central Informatics Organization [CIO], located at National Smart Card Centre [NSCC], Building 1088, Road 4025, Block 842, Isa Town and Government Data Network Centre, 1091, Road 4225, Juffair 342, and both locations are in the Kingdom of Bahrain and provide for the operation of the National ID card, identity verification and validation of the citizens and residents of the Kingdom of Bahrain is in the business of providing Digital Certificates [14] and related Public Key Infrastructure [PKI [30]] services, are committed to preserving the confidentiality, integrity and availability of all the physical and electronic information assets throughout the CIO CA [4] and RA areas in order to preserve the integrity, reputation and security of the citizens, residents and Government Departments and Agents it serves. Information and information security requirements will continue to be aligned with the CIO goals and the ISMS is intended to be an enabling mechanism for information sharing, for electronic operations and for reducing information-related risks to acceptable levels.
    The CIO’s current strategic business plan and risk management framework provide the context for identifying, assessing, evaluating and controlling information-related risks through the establishment and maintenance of an ISMS. The risk assessment, Statement of Applicability and risk treatment plan identify how information-related risks are controlled. The Information Security Manager is responsible for the management and maintenance of the risk treatment plan. Additional risk assessments may, where necessary, be carried out to determine appropriate controls for specific risks.
    In particular, business continuity and contingency plans, data back up procedures, avoidance of viruses and hackers, access control to systems and information security incident reporting are fundamental to this policy. Control objectives for each of these areas are contained in the Manual and are supported by specific, documented policies and procedures.
    All employees of the CIO [and certain external parties identified in the ISMS] are expected to comply with this policy and with the ISMS that implements this policy. All staff, and certain external parties, will receive appropriate training, initially by the Digi-CAST3™ Team and ultimately by the Information Security Manager.

    The CIO has established Trust Centre top-level management steering committee chaired by the Director General of IT and including the President of the CIO and the Chief Security Officer to support the ISMS framework and to periodically review the security policy.

    The CIO is committed to achieving certification [10] of its ISMS to ISO27001:2005

    This policy will be reviewed to respond to any changes in the risk assessment or risk treatment plan and at least annually.
    In this policy, “information security” is defined as:
    preserving
    This means that management, all full time or part time staff, sub contractors, project consultants and any external parties have, and will be made aware of, their responsibilities (which are defined in their job descriptions or contracts) to preserve information security, to report security breaches (in line with the policy and procedures identified in Section 13 of the Manual) and to act in accordance with the requirements of the ISMS. The consequences of security policy violations are described in the [organization’s] disciplinary policy. All staff will receive information security awareness training and more specialized staff will receive appropriately specialized information security training
    the availability.
    This means that information and associated assets should be accessible to authorized users when required and therefore physically secure. The computer network identified as part of the scoping work for Section 1 of the Manual is resilient and the organization is able to detect and respond rapidly to incidents (such as viruses and other malware) that threaten the continued availability of assets, systems and information. There are appropriate business continuity plans to meet the requirements of the CIO Trust Centre as approved by the Director General of IT.
    Confidentiality
    This involves ensuring that information is only accessible to those authorized to access it and therefore to preventing both deliberate and accidental unauthorized access to the CIO Trust Centre’s information and proprietary knowledge and its systems including its network(s), website(s), extranet(s), and e-commerce systems.

    And integrity
    This involves safeguarding the accuracy and completeness of information and processing methods and therefore requires preventing deliberate or accidental, partial or complete, destruction, or unauthorized modification, of either physical assets or electronic data. There must be appropriate contingency [including for network(s), e-commerce system(s), web site(s), extranet(s)] and data back-up plans, and security incident reporting. The CIO Trust Centre will comply with all relevant data-related legislation in the Kingdom of Bahrain within which it operates.
    Of the physical (assets)

    The physical assets of the CIO Trust Centre including but not limited to computer hardware, data cabling, telephone systems, filing systems and physical data files and information assets
    The information assets include information printed or written on paper, transmitted by post or shown in films, or spoken in conversation, as well as information stored electronically on servers, web site(s), extranet(s), intranet(s), PCs, laptops, mobile phones and PDAs as well as on CD ROMs, floppy disks, USB sticks, back up tapes and any other digital or magnetic media, and information transmitted electronically by any means. In this context “data” also includes the sets of instructions that tell the system(s) how to manipulate information (i.e. the software: operating systems, applications, utilities, etc)
    of the CIO.
    The CIO Trust Centre and such partners that are part of our integrated network and have signed up to our security policy and have accepted our ISMS.

    The ISMS is the Information Security Management System, of which this policy, the information security manual (“the Manual”) and other supporting and related documentation is a part, and which has been designed in accordance with the [specification contained in ISO27001:2005]

    A SECURITY BREACH

    A SECURITY BREACH is any incident or activity that causes or may cause a break down in the availability, confidentiality or integrity of the physical or electronic information assets of the Organization.

    The Information Security Manager is the Owner of this document and is responsible for ensuring that this policy document is reviewed in line with the requirements in clause 5.1.2 in the Manual.

    A current version of this document is available to all members of staff on the on request and as it does not contain confidential information, it can be released to relevant external parties.

    This information security policy was approved by the Trust Centre Committee and the Directors of the CIO on 08 November, 2007 and is issued on a version-controlled basis under the signature of the Information Security Manager.

    Shaikh Salman Mohammed Al-Khalifa Mohammed Al-Amer
    Director General of IT President of CIO

    ____________________________ _______________________________
    On:

    08 November, 2007 08 November, 2007
    ____________________________ _______________________________

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

    5.1.2 Review of the information security policy

    The Organisation’s information security policy is reviewed at planned intervals, or when and if significant changes occur, to ensure its continuing suitability, adequacy, and effectiveness.

      5.1.2.1The Information Security Manager is the Owner of the information security policy and has approved management responsibility for the development, review and evaluation of the policy.

      5.1.2.2The Organisation has a defined procedure (DOC 5.2) for the management review of the information security policy, and this includes continuous improvement, and assessing policy changes that might be necessary in response to significant changes in the organisational environment, business circumstances, legal conditions or technical environment.

      Note: The Information Security Manager accepts his role as owner of this document and intends to conduct several internal audits before 30 November, 2007 to ensure all aspects of the ISMS are correct, accurate and that this ISMS accurately reflects the total CIO Trust Centre environment.

      5.1.2.3 All changes to the information security policy are subject to approval by the Organisation’s board.

      Adlin Hisyamuddin
      Information Security Manager
      ____________________________

      On:

      08 November, 2007
      ____________________________

      Change history

      Issue 1 08 November, 2007 Initial issue


6. Organisation of Information Security

6 Organisation of Information Security

6.1 Internal Organisation

PDF [29] Control objective: management of information security within the Organisation and establishment of a management framework for the initiation, implementation and control of the ISMS.

    6.1.1 Management commitment to information security

    The Organisation’s management actively supports information security within the Organisation through clear direction, demonstrated commitment, explicit assignment and acknowledgement of its – and everyone else’s - information security responsibilities.

      6.1.1.1 The board has, in approving this Manual and the information security policy, expressed its clear support for information security within the Organisation and ensured that the information security policy meets identified information security risks and supports the business goals.

      6.1.1.2 The board has explicitly assigned lead responsibility for information security, in the management team, to the Director General of IT (also referred to in the organisational structure in Appendix III as the “Change Manager”)

      6.1.1.3 The board has allocated clear responsibilities to management and specific individuals for specific aspects of information security and these responsibilities are documented throughout the ISMS.

      6.1.1.4The board has ensured that there are adequately funded, resourced and trained to provide the level of information security it requires.

      6.1.1.5The board has identified the need for specialist information security advice and has appointed Digi-Sign & Vigitrust to provide this expertise, reporting to the Director General of IT. The Director General of IT is responsible for reviewing the effectiveness and value of this advice and ensuring that it is co-ordinated across the Organisation.

      6.1.1.6 The board has set up a dedicated management group to support the Director General of IT in managing information security within the Organisation, to be called the Information Security Committee. The goals of this committee, its members and its method of working are set out in procedure DOC 6.1.

    6.1.2 Information security co-ordination

    Due to the small size of the organisation, it co-ordinates its information security activities through a the Trust Centre Managers consisting of Director General of IT and the Information Security Manager from different parts of the organisation who have relevant roles and job functions

      6.1.2.1 The goals of the managers and methods of working are set out in procedure DOC 6.2.

      The Organisation has clearly defined all information security responsibilities.

    6.1.3 Allocation of information security responsibilities

      6.1.3.1 Responsibilities for specific information security procedures are clearly defined throughout the ISMS, and are documented in individual job descriptions in line with the requirements of 8.1.1 below.

      6.1.3.2 The Director General of IT, who has lead responsibility in the management team for information security (see 6.1.1.2 ) for the development, implementation and maintenance of the ISMS.

      6.1.3.3 The Information Security Manager reports to the Director General of IT.

      6.1.3.4 The Information Security Manager’s responsibilities are documented in his job description and includes the day-to-day responsibility for the implementation and maintenance of the ISMS.

      The Organisation has clearly defined all information security responsibilities

      6.1.3.5 All staff (and certain third party contractors) have accepted their specific responsibilities in the User Agreements which they sign before they are authorized to access organisational information assets.

      6.1.3.6 All information assets have been identified (see 7.1.1 [32]) and the security processes associated with each asset have been defined following a risk assessment (see sub section 4.4 [32]) and documented on the asset inventory schedules (see sub section 7.1 [32]).

      6.1.3.7 All assets have identified Owners (see 7.1.2 [32]), whose responsibility for the day-to-day maintenance of the controls applied to their asset is documented in their job descriptions (see 8.1.1 [32]) and elsewhere through the ISMS.

      6.1.3.8 The two sites have an identified Site Manager, the Information Security Manager, who is responsible for co-ordinating information security activities or carrying out specific processes within the two sites in line with the Manual and applicable procedures. The authority of this individual is in their job descriptions (see 8.1.1 [32]).

      6.1.3.9 Authorisation levels are clearly defined and documented (see manual sub section 2.2) and enforce segregation of duties (see 10.1.3 [32]).

    6.1.4 Authorisation process for information processing facilities

    The Organisation has defined and implemented a management authorisation process (see DOC 6.4) for new information processing facilities.

    6.1.5 Confidentiality agreements

    A confidentiality and non-disclosure agreement (DOC 6.5) reflecting the Organisation’s requirements for the handling of information is in place (also see 8.1.3 [32]) and is reviewed regularly

    6.1.6 Contact with authorities

    The Organisation maintains appropriate contacts with relevant authorities

      6.1.6.1The Information Security Manager is responsible for identifying (DOC 6.6) those authorities with whom the Organization needs to maintain contacts, to support information security incident management (sub section 13.2, below), business continuity management (Section 14, below), and continuous improvement.

    6.1.7 Contact with special interest groups

    The organisation maintains appropriate contact with special interest groups and other specialist security forums and professional associations

      6.1.7.1 The Information Security Manager is responsible, on behalf of the Organisation, for identifying and joining those forums and special interest groups which he considers will enable him to effectively meet the responsibilities contained in his job description.

      6.1.7.2 The Information Security Manager is required to ensure the Organisation has up-to-date information security knowledge, including about the changing malware threat environment.

      6.1.7.3 The Organisation’s Information Security Incident Management procedure (see Section 13 [32]) requires the Information Security Manager to have suitable liaison for dealing with incidents

    6.1.8 Independent review of information security
    The Organisation’s approach to managing information security and its implementation (i.e. control objectives, controls, policies, rules, processes and procedures for information security) is independently reviewed at planned intervals, and when significant changes to the security implementation occur.

      6.1.8.1 The Director General of IT is responsible for organizing independent audits of the ISMS. Where necessary, the Director General of IT in conjunction with the Information Security Manager engages expert (technical) external assistance. The audit procedures are contained in DOC 6.7 and sub section 15.3 of this Manual is also applicable.

      6.1.8.2 The ISMS is also subject to periodic reviews by external compliance [33] auditors.

      6.1.8.3 Risk assessments are [independently] reviewed annually to ensure that they are still complete and up-to-date.


6.2 External Parties

Control objective: to maintain the security of organisational information processing facilities and information assets that are accessed, processed, communicated to or managed by external parties

    6.2.1 Identification of risks related to external parties

    The Organisation’s procedures for identifying risks to its information assets and information processing facilities from business processes involving external parties, and for implementing appropriate controls before granting access, are identified in DOC 6.8.

    6.2.2 Addressing security when dealing with customers

    All identified security requirements are addressed, in line with the procedure in DOC 6.8 and the Organisation does not apply this control because none of its customers access any of its information assets.

    6.2.3 Addressing security in third party agreements

    Agreements with third parties involving accessing, processing, communicating or managing organisational information assets or information processing facilities, or adding products or services to information processing facilities, contain or refer to all identified security requirements, as required in DOC 6.8, and third parties are not allowed to access the Organisation’s information assets until such an agreement has been signed.

      6.2.3.1 Where an external provider has a standard agreement and no provision to vary it to meet a client’s requirement, the external parties standard clauses are assessed against the Organisation’s requirements and the risk associated with the gap is assessed before deciding whether or not to proceed with the offered terms. Where there is a significant variation between the requirements and what is offered, the Director General of IT’s approval to proceed with the provider is required.

6.3 Authorizing New Information Processing Facilities

    6.3.1 Scope
    The Organization requires that the procurement of all information processing facilities be subject to a formal authorization process in respect of information security.

    “Facility” is defined as “any system(s) or device(s) that will be used to process or store organizational information or that will connect to an organizational network or other information processing facility.” It includes hardware, software and services.

    6.3.2 Responsibilities

      6.3.2.1 The Information Security Manager is responsible for business approvals.
      6.3.2.2 The Site managers have responsibility for site approvals
      6.3.2.3 The Information Security Manager has responsibility for technical approval
      6.3.2.4 The Information Security Manager has responsibility for security approval
      6.3.2.5 The Director General of IT is responsible for procurement

    6.3.3 Procedure

    a) Approved (as to adequacy for the business purpose) and authorized by the line manager who/whose team will use them (business approval);
    b) Approved and authorized by the local Site Managers (see 6.1.3.8) as to meeting all relevant security policies and requirements are met (site approval);
    c) Approved and authorized by the IT Manager as to compatibility with current (and planned future) system components (technical approval);
    d) Approved and authorized by the Information Security Manager as to meeting information security requirements (e.g. information classification, anti-malware, etc) (security approval).
    e) Signatures and dates must be on the procurement documentation before the procurement can proceed.

    6.3.4 Information Processing Devices

    User-level information processing devices (notebooks, PDAs, mobile phones, etc) are all considered as “facilities” in terms of this procedure and the Organization requires each individual deployment of any such device to be approved and authorized in line with this procedure. Where relevant, a risk assessment will be carried out in line with DOC 4.4 [32]

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

7. Asset Management

Control objective: to achieve and maintain appropriate protection of organizational assets.

PDF [29] 7.1.Responsibility for Asset

    7.1.1 Inventory of assets

    All information assets are clearly identified, and an inventory of all important assets has been drawn up and is maintained in line with the requirements of DOC 7.1

    7.1.2 Ownership of assets

    All assets associated with the information systems or services are ‘owned’ by a designated individual or part of the Organisation, and details of the Owner are identified on the asset inventory in line with DOC 7.1.

    7.1.3 Acceptable use of assets

    Rules for the acceptable use of information and assets associated with information processing facilities have been identified, documented and implemented.

      7.1.3.1 The Civil Service Bureau, that ultimately reported to the Director General of IT, is responsible for ensuring that all users sign User Agreements (see sub section 11.2 [32]), which set out requirements for acceptable use of information assets and in which they also explicitly accept the Organisation’s Internet Acceptable Use Policy (DOC 7.2).

      7.1.3.2These User Agreements (see sub section 11.2 [32]) also explicitly accept the Organisation’s Rules for Use of E-mail (DOC 7.3).

      7.1.3.3The Information Security Manager is responsible for monitoring compliance, as set out in Work Instruction DOC 7.4, with the AUP as set out in 5.1.1 of this manual

      7.1.3.4Guidelines for the use of mobile devices are included in the ‘mobile on the road’ annex to the User Agreement (see sub sections 11.2 [32] 11.7 [32]) for users issued with such devices.


7.2 Information Classification

Control objective: to ensure that information receives an appropriate level of protection

    7.2.1 Classification guidelines

    Information has been classified in terms of value, legal requirements, sensitivity and criticality to the Organisation

      7.2.1.1 The Organisation has developed guidelines for information classification, which are suited to business needs (including legality, value, sensitivity and criticality) to both restrict and share information, and to the business impacts associated with those needs, and these are contained in DOC 7.6

    7.2.2 Information labelling and handling
    An appropriate set of procedures for information labelling and handling has been developed in accordance with the classification scheme adopted by the Organisation and this is set out in DOC 7.6

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

8. Human Resource Security

Control objective: to ensure that all employees, contractors and third party users understand their responsibilities, and are suitable for the roles they are considered for, and to reduce the risk of theft, fraud or misuse of facilities.

PDF [29] 8.1 Prior to Employment

    8.1.1 Roles and responsibilities

    Security roles and responsibilities of employees, contractors and third party users have been defined and documented as required by the Organisation’s information security policy.

      8.1.1.1 The Civil Service Bureau is responsible for ensuring that the Organisation has standard job descriptions for all roles, that contain defined security roles and responsibilities, and that these apply to all users of Organisational information assets. Job descriptions are provided to all prospective users prior to their recruitment.

      8.1.1.2 The Information Security Manager is responsible for ensuring that information security and IT staff have specific information security responsibilities and that these are detailed in their job descriptions.

      8.1.1.3 The Civil Service Bureau is responsible for ensuring that all users sign User Agreements (see 11.2 [32]) before they are allowed to access Organisational information assets; these User Agreements contain specific information security responsibilities.

      8.1.1.4 Owners of information assets have specific responsibilities, and these are documented in sub section 7.1.2 above.

      8.1.1.5Other responsibilities are identified as necessary throughout the ISMS.

    8.1.2 Screening

    Background verification checks on all candidates for employment, contractors and third party users are carried out in line with DOC 8.1 and in accordance with the laws, regulations and ethics of the Kingdom of Bahrain, and proportional to the Organization business requirements, the classification of the information to be accessed, and the perceived risks

    8.1.3 Terms and conditions of employment
    Employees, contractors and third party users must agree and sign the terms and conditions of their employment contract, which state their and the Organization responsibility for information security

8.2 During Employment
Control objective: to ensure that all employees, contractors and third party users are aware of information security threats and concerns, their responsibilities and liabilities, and are equipped to support organizational security policy in the course of their normal work, and to reduce the risk of human error.

    8.2.1 Management responsibilities
    Management requires employees, contractors and third party users to apply security in accordance with the policies and procedures of the Organization ISMS
      8.2.1.1 Management ensures that employees, contractors and third parties are appropriately briefed prior to being granted access to Organizational information assets (see 8.2.2).

      8.2.1.2 Management ensures that employees, contractors and third parties receive guidelines on security expectations (User Agreement, job descriptions and terms and conditions of employment).

      8.2.1.3 Management provides personal leadership and example in information security and ensures that the Organization policies and procedures are followed (see 6.1.8 [32]).


    8.2.2. Information security awareness, education and training

    All employees of the Organization and, where relevant, contractors and third party users receive appropriate awareness training and regular updates in organizational policies and procedures, as relevant for their job function.

      8.2.2.1 The Information Security Manager is responsible for ensuring that all users receive standard information security induction and awareness training before they are allowed to access Organizational information assets. This includes the incident reporting procedure.

      8.2.2.2 The Information Security Manager is responsible fore ensuring that all users receive regular updates and alerts on information security issues as and when necessary, and that additional security-related training is made available as and when required.

      8.2.2.3 The Information Security Manager is responsible for ensuring that specialized information security staff receive appropriate specialist training in line with their job requirements.

    8.2.3 Disciplinary process

    The Organisation has a formal disciplinary process for employees who have committed a security breach

      8.2.3.1 Breaches of the Organisation’s ISMS may be treated as misconduct in terms of the Organisation’s disciplinary policy as issued by the Civil Service Bureau (which is set out in [where?]) and serious breaches may lead to dismissal.

8.3 Termination or Change of Employment
Control objective: to ensure that employees, contractors and third party users exit an organisation or change employment in an orderly manner

    8.3.1 Termination responsibilities
    Responsibilities for performing employment termination have been clearly defined and assigned by the Civil Service Bureau.

    8.3.2 Return of assets
    All employees, contractors and third party users are required to return all Organisational assets in their possession upon termination of their employment, contract or agreement.

    8.3.3 Removal of access rights
    The access rights of all employees, contractors and third party users to information and information processing facilities are removed upon termination of their employment, contract or agreement, or adjusted upon change

    Shaikh Salman Mohammed Al-Khalifa Mohammed Al-Amer
    Director General of IT President of CIO

    ____________________________ _______________________________

    On:

    08 November, 2007 08 November, 2007
    ____________________________ _______________________________

9. Physical & Environment Security

Control objective: to prevent unauthorized physical access, damage and interference to the organization premises and information.

PDF [29] 9.1 Secure Areas

    9.1.1 Physical security perimeter

    The Organization uses security perimeters to protect areas that contain information and information processing facilities.

      9.1.1.1 All the Organization sites have physical security perimeters. The minimum specification checklist for the physical security perimeter is in DOC 9.7 and the Information Security Manager ensures that each site is checked on a monthly basis.

      9.1.1.2 The Information Security Manager is responsible for maintaining both site’s secure perimeter.

      9.1.1.3 The Organization central information processing facilities are within secure areas, each of which have Owners (see sub section 7.1.2 [32]) that are themselves within a site’s secure perimeter.

      9.1.1.4 The Information Security Manager has a site map for each site or secure area, together with a current security checklist DOC in sub section 9.7 that identifies the current state of conformity to the requirements in that checklist.

    9.1.2 Physical entry controls
    Secure areas are protected by appropriate entry controls to ensure that only authorized personnel are allowed access.

      9.1.2.1 A risk assessment (see sub section 4.4 [32]) is used to determine the type of entry controls that might be required for secure areas and these are implemented in line with the requirements of DOC 9.6 and DOC 9.8.

      9.1.2.2The Information Security Manager is responsible for maintaining required physical entry controls.

    9.1.3 Securing offices, rooms and facilities

    The Organization has designed and applied physical security for offices, rooms and facilities.

      9.1.3.1The Organization conducts risk assessments (DOC 4.4 [32]) of individual offices, rooms and facilities that contain confidential or high risk information assets to identify the controls that might be necessary to secure them. These are implemented in line with DOC 9.7. There are no sites where confidential information processing facilities are shared with a third party organization, other than under the terms of a contract (see sub section 6.2.3 [32])


    9.1.4 Protecting against external and environmental threats

    The Organization has designed and applied physical protection against damage from fire, flood, earthquake, explosion, civil unrest, and other forms of natural or man-made disaster

      9.1.4.1The Organization has assessed the risk of external and environmental threats and has applied controls that are included in DOC 9.7 or that are part of the Business Continuity Management framework (see Section 14 [32]).

    9.1.5 Working in secure areas

    The Organization has designed and applied physical protection and guidelines for working in secure areas and these are contained in DOC 9.8.

    9.1.6 Public access, delivery and loading areas

    Access points such as delivery and loading areas and other points where unauthorized persons may enter the premises are controlled and isolated from information processing facilities to avoid unauthorized access.

      9.1.6.1The Organization controls for delivery and loading areas are detailed in DOC 9.9.

9.2 Equipment security

Control objective: to prevent loss, damage, theft or compromise of assets and interruption to the organization activities

    9.2.1 Equipment site locating and protection

    Equipment is sited and protected to reduce the risks from environmental threats and hazards, and opportunities for unauthorized access

      9.2.1.1 The Information Security Manager is responsible for implementing the requirements of DOC 9.10, which include this control.

    9.2.2 Supporting utilities
    Equipment is protected from power failures and other disruptions caused by failures in supporting utilities.

      9.2.2.1The Information Security Manager is responsible for implementing the requirements of DOC 9.10, which include this control.

    9.2.3 Cabling security
    Power and telecommunications cabling carrying data or supporting information services is protected from interception or damage

      9.2.3.1The Information Security Manager is responsible for implementing the requirements of DOC 9.10, which include this control.

    9.2.4 Equipment maintenance
    Equipment is correctly maintained to ensure its continued availability and integrity

      9.2.4.1The Information Security Manager is responsible for implementing the requirements of DOC 9.10, which include this control.

    9.2.5 Security of equipment off-premises

    Security is applied to off-site equipment taking into account the different risks of working outside the Organization premises

      9.2.5.1Users of mobile equipment are required, as part of their User Agreements (see 11.1 [32]), to provide appropriate physical security for equipment when off-site and to ensure that manufacturer’s instructions for protecting equipment are followed.

      9.2.5.2 Home working is not permitted for the Trust Centre.

      9.2.5.3 The Organization specifically does not provides cover against loss of or damage to mobile devices because no mobile divides are used by the Trust Centre.


    9.2.6 Secure disposal or re-use of equipment
    All items of equipment containing storage media are checked to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal

      9.2.6.1The Organization has a standard procedure (DOC 9.11) to ensure that storage media are made safe for disposal.

    9.2.7 Removal of property
    Equipment, information or software may not be taken off-site without prior authorization as required by DOC 9.12


9.7 Additional requirements

    9.7.1 All organizational sites that contain information processing facilities are required to conform to the following minimum specification. Additional requirements may, dependent on a risk assessment, be applied to any site. In such cases, details of the risk assessment will be attached to the copy of this list.

    9.7.2 If there is a computer or communications room or other designated secure area within one of the Organization’s sites, treat it as a separate set of premises and complete a checklist for each room AS WELL AS for the site.

    9.7.3Ensure any Health and Safety issues have been identified and resolved.

    PREMISES INSPECTION
    Site Address:

    Date and time of Inspection:
    Inspector:

    9.7.3 Attach a current site (room) map, with the physical security perimeter clearly marked.

    9.7.4 Identify and list the information assets that are on the site together with their information security classification:

    9.7.5 Checklist (identify improvement requirements):

    a) Completeness of perimeter:
    b) External walls of solid construction:
    c) Access possible over walls/through roof?
    d) Access possible under walls?
    e) External doors solid?
    1. With required locks/breach alarms?
    2. With automatic closing mechanisms?
    3. Remote access doors protected by cameras?
    f) External windows locked/barred?
    g) Fire doors alarmed and monitored in accordance with Work Instruction DOC 9.2
    h) Fire alarms installed and working (DOC 9.2)
    i) Fire suppression equipment installed and working (DOC 9.4)
    j) Burglar/intruder alarms installed and working (DOC 9.3)
    1. All [accessible] external windows covered?
    2. All external doors covered?
    3. Unoccupied areas alarmed at all times?
    4. Reception area controlled (DOC 9.6)
    k) Air conditioning installed and working (DOC 9.5)
    l) Health and safety regulations [insert details of relevant code] applied?
    m) (If it houses systems processing confidential information) how easy is it for the public to access the facility?
    n) (If it houses systems processing confidential information) how unobtrusive is this to the public? Are there any obvious signs of information processing activities?
    o) Are internal directories appropriately classified to restrict access to details of confidential sites?
    p) Are hazardous, combustible materials safely stored (at a safe distance from a secure area)?
    q) Are bulk supplies of non-confidential items stored outside secure areas?
    r) Are necessary fire extinguishers available [insert details of requirements] and tested [insert details of testing regime]?

    Distribution: copies of this report are held by the Premises Security Manager and the Information Security Manager.

    The Site Security Managers at the CIO are the owners of this document and is responsible for ensuring that this procedure is reviewed in line with the review requirements of the ISMS.


9.8 Physical Entry Controls & Secure Areas

    1 Scope [ISO 17799 clauses 9.1.2 and 9.1.3]

    All designated secure areas (see DOC 9.7 and DOC 9.10) on any of the Organization’s premises are subject to controlled access and usage.

    2 Responsibilities

      2.1 Every secure area has an Owner (see sub section 7.1.2 [32] of the Manual) and the Owner is responsible for ensuring that prescribed controls are maintained and as otherwise specified below.

      2.2 The [Site Manager/secure area Owner] is responsible for authorizing access to secure areas.

      2.3 All employees, contractors and third parties have certain responsibilities as defined below. Procedure

    3 Secure areas must be locked at all times. The lock specification is as set out in sub section 11.1 [32] of this manual. The Owner must check the secure area at least once per day, even if no-one is working in it.

    4 Access to secure areas/areas where confidential or restricted information is processed (including in conversation) or stored is restricted to authorized persons. Authorization is provided as set out in sub section 11.1 [32] of this manual.

    5 Access to secure areas requires authentication and authorized persons are issued with username and password access controls as provided and set out in sub section 11.1 [32] of this manual.

    6 The Owner of a secure area is responsible for ensuring that no unsupervised working takes place within the secure area.

    7 The authentication system retains a record of accesses and these are reviewed monthly to identify any unauthorized accesses.

    9 The Owner of a secure area is responsible for ensuring that photographic, video, audio or other recording equipment and mobile phone cameras are not taken into the secure area.

    10 All employees, contractors and third parties are required to wear an identification badge issued by the Guards at the entry point to the National Smart Card Centre on arrival. These ID cards are only issued upon presentation and verification of a Passport or CPR card and are required to notify security if they encounter unescorted visitors and anyone not wearing required identification (see DOC 9.6).

    11 Third party support personnel only have access to secure areas when required and this access is specifically requested, authorized and monitored as set out in sub section 11.1 [32] of this manual.

    12 In general, the Owner of a secure area and all those who are authorized to work within it, are required only to divulge details of the area and what is done in the area to other staff on a need to know basis.


9.10 Equipment Security

All information processing equipment owned or used by the Organization is subject to secure site location and protection requirements.

    9.10.2 Responsibilities
      9.10.2.1The Owner of an information asset as described in this ISMS is responsible for the site location and protection of information equipment.

      9.10.2.2 The Site Managers are responsible for ensuring that equipment is protected from possible power supplies and other power-related disruptions.

      9.10.2.3 The Site Managers are responsible for cabling security.

      9.10.2.4 The Site Managers are is responsible for maintenance of equipment.

      9.10.2.5 The Site Managers are responsible for the secure site location or all telecommunications facilities.

      9.10.2.6 The Information Security Manager is responsible for defining and resourcing business continuity needs.

      9.10.2.7The Director General of IT is responsible for insurance.

      9.10.2.8 Where necessary, other responsibilities are identified in the course of this procedure.

      9.10.2.10 Access to secure areas is controlled in line with DOC 9.8.

    9.10.3 Site location and protection of equipment [ISO 17799 clause 9.2.1]

    The requirements are:

    a) That equipment is sited so as to minimize [public/unnecessary] access to work areas;
    b) Information processing and storage equipment (including faxes, photocopiers and telephone equipment used for confidential information) is sited in secure areas [server/communications rooms/secured offices] so that it is not possible for confidential information to be seen by unauthorized people;
    c) Secure areas are subject to the same level of physical perimeter protection as secure sites;
    d) Equipment that requires special protection is isolated in the CA [4] Inner Core Room;
    e) Controls are implemented to deal with theft (see sub section 9.1 of the Manual), natural or man-made disaster (see sub section 9.1.4 of the Manual).
    f) The Organization does not allow smoking inside any of its sites, nor does it allow eating or drinking inside secure areas;
    g) Secure areas are monitored for temperature increases above X degrees Celsius and an acceptable limit has been set at X degrees Celsius and the Information Security Manager receives an immediate alert as set out in the OWI for the fire detection system once they are breached.

    9.10.4 Supporting utilities [ISO 17799 clause 9.2.2]

      9.10.4.1 All servers and communications equipment used for the CA project are in secure areas that have adequate power supplies. For each secure area, the maximum power requirements are calculated by reference to the manufacturer’s recommendations for each device plus the requirements for other items running off the same supply plus an element for buffer to be allow for ongoing changes and the Site Managers have incoming power cables checked by cleared suppliers to ensure that they supply adequate power. Offices and other (non-secure) areas that contain information-processing equipment are similarly assessed to ensure that power supplies are adequate.

      b) The Site Managers are responsible for ensuring that Heating and Ventilation engineers provide a formal report on the heating, cooling/air conditioning and ventilation requirements of each secure area and each site that contains information processing equipment and for reporting on the adequacy or otherwise of current installations. Shortfalls in requirements are to be treated by escalating their concerns to the Information Security Manager for Risk Assessment, treatment and the creation of an Operation Work Instruction [OWI] as necessary.

      c) The Site Managers are responsible for ensuring that all supporting utilities and equipment is inspected (also see DOC 9.7 and DOC 9.8) on a frequency determined by manufacturer’s recommendations [and previous inspections] and that inspection certificates are retained in line with sub section 15.1.3 of the Manual.

      9.10.4.2 A UPS is installed outside each secure area and their operation and working are outside the scope of this ISMS other than to state that they are available and operational as a ‘fail over’ power supply. The Information Security Manager has assessed the risk of their failure and prepared the OWI in Appendix III to address the Risk associated with this system.

    9.10.5 Cabling security [ISO 17799 clause 9.2.3]

      9.10.5.1The Information Security Manager has a site map that identifies all network cabling and all incoming power and all lines are protected.

      9.10.5.2Network cabling is protected from unauthorized access by virtue of this being a closed network and power and network cables are segregated using separate conduits and clearly marked for ease of maintenance on the site map.

      9.10.5.3Connections between these are further protected by:
      a) Electromagnetic shielding for cables;
      e) Technical sweeps and physical inspections that are carried out by the Information Security Manager and/or the Security Administrator to ensure that no unauthorized devices are attached to cables.

    9.10.6 Equipment maintenance [ISO 17799 clause 9.2.4] Information Security Manager

      9.10.6.1 The Information Security Manager is responsible for ensuring that all equipment on the site is maintained in line with manufacturers’ recommended service intervals and specifications. The Information Security Manager is maintains a schedule of all equipment, showing its due and actual service dates, and retains copies of the service reports, together with fault reports and details of preventative or corrective action (also see DOC 9.7).

      9.10.6.2 Only authorized and experienced maintenance personnel and only from suppliers identified on the current signed Asset List are permitted to carry out maintenance at the Trust Centre in line with the policy set out in sub section 11.1 [32] of this manual.

      9.10.6.3 Equipment that processes or stores confidential information is serviced only by technicians who have been screened in line with the requirements of 8.1.2 of the Manual is cleaned of confidential information prior to servicing.

      9.10.6.4 The Organization’s insurance policy is the responsibility of the Director General of IT and is outside the commitments normally associated with a private enterprise.

      Scope

      The Organization requires, under sub section 9.2.6 of the Manual, that all removable storage media are clean (which means: it is not possible to read or re-constitute the information that was stored on the device or document) prior to disposal.

      Responsibilities

      The Information Security Manager is responsible for managing the secure disposal of all storage media in line with this procedure when they are no longer required, and is the Owner of the relationship with Al Falwa Cleaning WLL who is the approved contractor for removing shredded documents.

      All Owners (see sub section 7.1.2 [32] of the Manual) of removable storage media are responsible for ensuring that these media are disposed of in line with this procedure.

      Procedure [ISO 17799 clause 9.2.6]

      Hard disks must be cleared of all software and all Organizational confidential and restricted information prior to disposal or re-use, as set out in clause 5 below.

      The Information Security Manager is responsible for the secure disposal of storage media and the disposal of all information processing equipment is routed through his/her office. A log (REC 9.1) is retained showing what media was destroyed, disposed of, and when. The asset inventory is adjusted once the asset has been disposed of.

      Hard disks are cleaned by the Security Administrator prior to destruction.

      Devices containing confidential information are broken and then burnt prior to disposal and are never re-used.

      Devices containing confidential information that are damaged are subject to a risk assessment prior to sending for repair, to establish whether they should be repaired or replaced in which case they are destroyed according to this procedure.

      Documents containing confidential and restricted information which are to be destroyed are shredded by their owners, using a shredder with an appropriate security classification. These shredders are located in the ISA Town National Smart Card Centre outside the Trust Centre. The waste is removed by the approved contractor.

      The Information Security Manager is the owner of this document and is responsible for ensuring that this procedure is reviewed in line with the review requirements of the ISMS.

      Yousif Mohammed Ali Muthanna Yousif Mohammed Abdulla
      Site Security Manager Site Security Manager

    ____________________________ ____________________________

    On: On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

10. Communications & Operations Management


10.1. Operational Procedures & Responsibilities

    PDF [29] 10.1.1 Documented operating procedures
    Operating procedures have been documented, are maintained and are made available to all users who need them
      10.1.1.1The Information Security Manager is responsible for documenting all the IT working procedures for system activities related to information processing and communications facilities. The procedures required by the Organisation are listed in DOC 10.1.

    10.1.2 Change management

    Changes to information processing facilities and systems are controlled

      10.1.2.1 The Director General of IT is responsible for ensuring that all requests for significant non-routine changes to Organisational information processing facilities are managed in line with DOC 10.7 and sub section 12.5 below is also relevant.

    10.1.3 Segregation of duties

    Duties and areas of responsibility are segregated to reduce opportunities for unauthorized or unintentional modification or misuse of organisational assets

      10.1.3.1 As far as is practicable and possible, the Organisation segregates duties and areas of responsibility. In particular, the following functions are segregated:

      1. Risk Assessment Adlin Hisyamuddin - Information Security Manager, Head PKI [30]
      2. Authorisation of Controls Mubarak Abdulla Alhiddi - CSO/CIO
      3. Change Initiation Ahmed Essa Abualfath - Computer Security Administrator
      4. Change Management Shaikh Salman Mohammed Al-Khalifa – Director General of IT
      5. Network Management Khalid Al Othman – Chief, Network
      6. Network Administration Khalid Ali Al Jalahma – Network Administrator
      7. IT Operations Mohammed Al-Yassi – Director IT Operations
      8. Software Development Sameh Abo-El-Ela
      9. System Testing Osama Khalid Rafai - Computer Security Administrator
      10. Employee Administration Hesham Al-Ghatam - Chief, Personnel & Admin’ Development
      11. Asset Purchase Khulood Al-Jassim - Supervisor Administration Service
      12. Site/Secure Area Security Adel Khalifa Bu-Alai - Chief of Police in Juffair
      13. Site/Secure Area Security Mohammed Hamdan Mohammed - Chief of Police in Isa Town
      14. Security Audit Osama Khalid Rafai - Computer Security Administrator
      15. PKI Manager Adlin Hisyamuddin - Information Security Manager, Head PKI
      16. Physical Site Security Yousif Mohammed Ali Muthanna – Site Security Manager
      17. Physical Site Security Yousif Mohammed Abdulla – Site Security Manager

      10.1.3.2 Segregation of duties is built into procedures, including the requirement that that the Owner of a procedure or process cannot authorize its modification, withdrawal or release.

      10.1.3.3 Activity monitoring, audit trails and management supervision are used to support duty segregation.

    10.1.4 Separation of development, test and operational facilities

    Development, test and operational facilities are separated to reduce the risks of unauthorized access or changes to the operational system

      10.1.4.1 The Organisation’s requirements for separate development, test and operational facilities, and its rules for their use and for the transfer of software to the operational environment are documented in DOC 10.8.

10.2 Third Party Service Delivery Management

Control objective: to implement and maintain the appropriate level of information security and service delivery in line with third party service delivery agreements

    10.2.1 Service delivery

    The Organization ensures that the security controls, service definitions and delivery levels included in the third party service delivery agreement are implemented, operated and maintained by the third party

      10.2.1.1 Third party relationship Owners (see sub section 6.2 [32] and 7.1.2 [32]) are required to ensure that security is maintained through transition periods and for ensuring that external parties deliver services and maintain security in line with their agreements, all as specified in DOC 6.8. [32]

      10.2.1.2 The Information Security Manager is responsible for ensuring that external party services are linked into the Organisation’s business continuity framework and arrangements (see Section 14 [32]).

    10.2.2 Monitoring and review of third party services
    The Organisation regularly monitors and reviews the services, reports and records provided by third parties and carries out regular audits

      10.2.2.1 The Organisation has a defined process (DOC 10.9) for managing third party service contracts.

    10.2.3 Managing changes to third party services

    The Organisation manages changes to the provision of services, including maintaining and improving existing information security policies, procedures and controls, taking account of the criticality of business systems and processes involved and re-assessment of risks, and the procedures for doing this are contained in DOC 6.8. [32]

10.3 System Planning & Acceptance

Control objective: to minimize the risks of systems failures

    10.3.1 Capacity management
    DOC 10.10 sets out the Organisation’s approach to ensuring that the use of resources is monitored, tuned, and projections made of future capacity requirements to ensure the adequate system performance.

    10.3.2 System acceptance
    Acceptance criteria for new information systems, upgrades and new versions have been established and suitable tests of the system(s) are carried out during development and prior to acceptance, all as specified in DOC 10.10. rotection

10.4 Protection Against Malicious & Mobile Code

Control objective: to protect the integrity of software and information

    10.4.1 Controls against malicious code

    Detection, prevention and recovery controls to protect against malicious code and appropriate user awareness procedures have been implemented

      10.4.1.1The Organization has a formal policy (DOC 10.11) prohibiting the use of unauthorized software, protecting against the risks associated with obtaining files from or via external networks, and has defined appropriate responsibilities and procedures (DOC 10.12) for dealing with the risks from malicious code.

    10.4.2 Controls against mobile code

    The execution of mobile code is prohibited in the Trust Centre

10.5 Back-Up

Control objective: to maintain the integrity and availability of information and information processing facilities

    10.5.1 Information back-up

    Back-up copies of information and software are taken and tested regularly in accordance with the agreed back-up policy below

      10.5.1.1 The Organization’s policy is that it acts to maintain the integrity and availability of information and information processing facilities by establishing criteria and routine procedures (in DOC 10.13) to ensure that all the Organization’s information assets are backed up and that there are tested procedures (see Section 14 [32]) for restoring them within an adequate time frame.

10.6 Network Security Management

Control objective: to ensure the safeguarding of information in networks and the protection of the supporting infrastructure

    10.6.1 Network controls

    Networks are managed and controlled as set out in DOC 10.14, in order to be protected from threats, and to maintain security for the systems and applications using the network, including information in transit

    10.6.2 Security of network services

    Security features, service levels and management requirements of all network services have been identified and included in the network service level agreement and are managed in line with DOC 10.14.


10.7 Media Handling
Control objective: to prevent the unauthorized disclosure, modification, removal or destruction of assets and interruption to business activities

    10.7.1 Management of removable computer media
    Procedure DOC 10.15 identifies the controls for the management of removable media.

    10.7.2 Disposal of media
    Media are disposed of securely and safely when no longer required, in line with DOC 9.11. [32]

    10.7.3 Information handling procedures
    Procedures for the handling and storage of information are set out in DOC 7.6 [32] and DOC 10.15 to protect this information from unauthorized disclosure or misuse

    10.7.4 Security of system documentation
    System documentation is protected against unauthorized access, as set out in DOC 10.15.


10.8 Exchanges of Information

Control objective: to maintain the security of information exchanged within an organization and with any external entity

    10.8.1 Information exchange policies and procedures

    Formal exchange policies, procedures and controls are in place to protect the exchange of information through the use of all types of communication facilities

      10.8.1.1 The Organization Internet Acceptable Use Policy (DOC 7.2 [32]), its e-mail usage rules (DOC 7.3 [32]), its information classification procedures (DOC 7.6 [32]), its anti-malware policy (DOC 10.11) and related procedures, and the technological controls implemented as required in all those procedures, protect exchanges of information from interception, unauthorized copying, modification, destruction or mis routing.

      10.8.1.2 The wireless user’s addendum to the standard User Agreement (see sub section 11.1 [32] of this Manual) sets out how wireless communication is protected.

      10.8.1.3 The mobile phone user’s addendum to the standard User Agreement (see sub section 11.1 [32] of this Manual) sets out how mobile voice communication is protected.

      10.8.1.4 The organization has a procedure (DOC 7.11) for secure voice communication at all its sites.

      10.8.1.5 The Organization use of cryptographic techniques is controlled under sub section 12.3 [32] below.

      10.8.1.6 The Organization has procedures for handling (DOC 10.15), retention (DOC 15.2 [32]) and disposal (DOC 9.11 [32]) of information and related media.

    10.8.2 Exchange agreements

    Agreements are established in line with DOC 6.8 [32] for the exchange of information and software between the Organization and external parties

    10.8.3 Physical media in transit

    DOC 9.12 [32] sets out how the Organization ensures that media are protected against unauthorized access, misuse or corruption during transportation beyond the Organization physical boundaries

    10.8.4 Electronic messaging
    Messaging is outbound only and no inbound email system exists within the CIO Trust Centre

    10.8.5 Business information systems

    A policy and procedures have been developed and implemented to protect information associated with the interconnection of business information systems.

      10.8.5.1 The Organization’s policy is that information should be as widely shared within the Organization as is permitted by its security classification (see DOC 7.6 [32]), that information should have as low a classification as is practical, given its sensitivity, and that information within its interconnected systems should be protected in line with its classification. Procedures (see DOC 10.16) have been developed to implement this policy.


10.9 Electronic Commerce Services
Control objective: to ensure the security of electronic commerce services, and their secure use

    10.9.1 Electronic Commerce

    Electronic commerce information passing over public networks is protected from fraudulent activity, contract dispute, and unauthorized disclosure and modification as set out in DOC 10.17.

    10.9.2 On-line Transactions
    Information involved in on-line transactions is protected in line with DOC 10.17 to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized message duplication or replay

    10.9.3 Publicly available information

    The integrity of information being made available on a publicly available system is protected in DOC 10.17 to prevent unauthorized modification


10.10 Monitoring
Control objective: to detect unauthorized information processing activities

    10.10.1 Audit logging

    Audit logs recording user activities, exceptions and information security events are produced and kept, in line with DOC 10.18, for a period specified in DOC 15.2 [32] to assist in future investigations and access control monitoring

    10.10.2 Monitoring system use

    Procedures for monitoring use of information processing facilities have been established in DOC 10.18 and the results of the monitoring activities are reviewed [regularly]

    10.10.3 Protection of log information

    Logging facilities and log information are protected against tampering and unauthorized access, as required by DOC 10.18
    10.10.4 Administrator and operator logs
    System administrator and system operator activities are logged as required by DOC 10.18

    10.10.5 Fault logging

    Faults are logged, analysed and appropriate action taken, all in line with DOC 10.18

    10.10.6 Clock synchronization

    The clocks of all relevant information processing systems within the organisation are synchronized with an agreed accurate time source as specified in DOC 10.18.

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

11. Access Control

Control objective: to control access to information

PDF [29] 11.1 Business Requirement For Access Control

    11.1.1 Access control policy

    An access control policy has been established, documented in DOC 11.1, and is reviewed when required in the light of business and security needs. In addition, as the Trust Centre protects National Assets, the following are the physical procedures that must be followed every time the Trust Centre in the National Smart Card Centre in Isa Town is accessed.

    Administration Area

    When access is required to the Administration Area of the Trust Centre, any two of following five members are required in addition to one of the Police Officers, tasked by Mohammed Hamdan Mohammed, to guard the Trust Centre must supervise their entry, and wait in attendance directly outside the door of the Administration Area until all the people that entered, exit at the same time. No one is ever permitted to enter the Trust Centre Administration Area alone, under any conditions. And no one is permitted to remain in the Trust Centre Administration Area unaccompanied by one of the following personnel:

    • Mubarak Abdulla Alhiddi
    • Osama Khalid Rafai
    • Adlin Hisyamuddin
    • Yousif Mohammed Ali Muthanna
    • Yousif Mohammed Abdulla

    If any of the above personnel are absent they can be represented/replaced by the Director General of IT, or the President of the CIO.

    Outer Core

    When access is required to the Outer Core Area of the Trust Centre, all three of following members are required in addition to one of the Police Officers, tasked by Mohammed Hamdan Mohammed, to guard the Trust Centre must supervise their entry, and wait in attendance directly outside the door of the Outer Area until all the people that entered, exit at the same time. No one is ever permitted to enter the Trust Centre Administration Area alone, under any conditions. And no one is permitted to remain in the Trust Centre Outer Core Area unaccompanied by all of the following personnel:

    • Mubarak Abdulla Alhiddi
    • Osama Khalid Rafai
    • Adlin Hisyamuddin

    If any of the above personnel are absent they can be represented/replaced by the Director General of IT, or the President of the CIO.

    Inner Core
    When access is required to the Inner Core Area of the Trust Centre, all three of following members are required in addition to one of the Police Officers, tasked by Mohammed Hamdan Mohammed, to guard the Trust Centre must supervise their entry, and wait in attendance directly outside the door of the Outer Area until all the people that entered, exit at the same time. No one is ever permitted to enter the Trust Centre Administration Area alone, under any conditions. And no one is permitted to remain in the Trust Centre Inner Core Area unaccompanied by all of the following personnel:

    • Mubarak Abdulla Alhiddi

    • Osama Khalid Rafai

    • Adlin Hisaymuddin Hisyamuddin

    If any of the above personnel are absent they can be represented/replaced by the Director General of IT, or the President of the CIO.

    Setting Access Control on the Idendix System

    Access to all areas of the Trust Centre is controlled by the Identix biometric locking system on all of the doors. The system is configured according to the policy set out in sub section 11.1 above. Only two people have the username and password to access this system:

    • Osama Khalid Rafai

    • Adlin Hisyamuddin

    The Identix control system is located in the Administration Area of the Trust Centre and as no one can access this area alone, both people will be monitored by one of the other personnel with access rights to the Administration Area. A change log must be signed by the Director General of IT or the President of the CIO to change the access configuration for any of the doors in the Trust Centre.

    No changes to this system are permitted without this change control document signed by the Director General of IT or the President of the CIO.

    In addition, as part of the monthly controls checking procedure, the Information Security Manager will check the los on the Identix system, print out these logs and sign them to demonstrate that no unauthorised changes have occurred without authorisation.


11.2 User Access Management

Control objective: to ensure authorized users’ access and to prevent unauthorised access to information systems

    11.2.1 User registration
    There is a formal user registration and de-registration procedure (DOC 11.3 and DOC 11.4) for granting and revoking access to all information systems and services

    11.2.2 Privilege management
    The allocation and use of privileges is restricted and controlled in DOC 11.3

    11.2.3 User password management
    The allocation of passwords is controlled through a formal management process as set out in DOC 11.3

    11.2.4 Review of user access rights

    Management reviews users’ access rights at regular intervals using the formal process as set out in DOC 11.3


11.3 User Responsibilities

Control objective: to prevent unauthorized user access, and compromise or theft of information and information processing facilities

    11.3.1 Password use

    Users are required (in their User Agreements DOC 11.4) to follow good security practices in the selection and use of passwords

    11.3.2 Unattended user equipment

    Users are required (in their User Agreements DOC 11.4) to ensure that unattended equipment has appropriate protection

    11.3.3 Clear desk and screen policy

    The Organisation has adopted a clear desk policy for papers and removable storage media and a clear screen policy for information processing facilities and the requirement for compliance [3] with this policy is set out in DOC 11.4.


11.4 Network Access Control

Control objective: to prevent unauthorized access to networked services

    11.4.1 Policy on use of network services
    The Organisation’s policy (in DOC 11.7) is that users are only provided with access to the services that they have been specifically authorized to use.

    11.4.2 User authentication for external connections

    DOC 11.8 sets out the authentication methods that are used to control access by remote users.

    11.4.3 Equipment identification in the network

    Automatic equipment identification is used as set out in DOC 11.8 as a means to authenticate connections from specific locations and equipment

    11.4.4 Remote diagnostic and configuration port protection

    Physical and logical access to diagnostic and configuration ports is controlled as required by DOC 11.8.

    11.4.5 Segregation in networks

    Groups of information services, users and information systems are segregated in the network(s) in line with the requirements of DOC 11.7 and 11.8

    11.4.6 Network connection control

    The Organization has a single shared network which extends across the organizational boundaries; the Organization restricts the capability of users to connect to the network, in line with the access control policy (DOC 11.1) and requirements of the business applications and as set out in DOC 11.8.

    11.4.7 Network routing control

    Routing controls have been implemented in line with DOC 11.8 for the Organization networks to ensure that computer connections and information flows do not breach the Organization access control policy as applied to the business applications


11.5 Operating System Access Control

Control objective: to prevent unauthorized access to operating systems

    11.5.1 Secure log-on procedure

    Access to information systems is controlled by the secure log-on procedure set out in DOC 11.9

    11.5.2 User identification and authentication

    All users have a unique identifier (user ID) for their personal and sole use, issued in line with the requirements of DOC 11.3, and [a suitable authentication technique] has been chosen to substantiate the claimed identity of a user

    11.5.3 Password management system

    The password management system set out in DOC 11.3 ensures quality passwords

    11.5.4 Use of system utilities

    The use of utility programs that might be capable of overriding system and application controls is restricted and controlled as specified in DOC 11.10.

    11.5.5 Session time-out

    Inactive sessions are shut down in accordance with DOC 11.9 after a defined period of inactivity

    11.5.6 Limitation of connection time

    Restrictions on connection times are used to provide additional security for high-risk applications, as specified in DOC 11.8.


11.6 Application & Information Access Control

Control objective: to prevent unauthorized access to information held in application systems

    11.6.1 Information access restriction

    Access to information and application system functions by users and support personnel is restricted in DOC 11.2 in accordance with the access control policy in DOC 11.1

    11.6.2 Sensitive system isolation

    Sensitive systems have a dedicated (isolated) computing environment as provided in DOC 11.9


11.7 Mobile Computing & Teleworking

Control objective: to ensure information security when using mobile computing and teleworking facilities

    11.7.1 Mobile computing and communications

    A formal policy is in place and appropriate security measures have been adopted to protect against the risks of using mobile computing and communication facilities

      11.7.1.1 The Organization’s mobile computing policy below covers notebook computers, palmtops, (PDAs), laptops, smart phones and mobile phones. The Organization provides mobile computing facilities in order to improve the productivity, flexibility, responsiveness and effectiveness of its operations. The Organization also takes appropriate steps for physical protection (User Agreement DOC 11.4), access controls, cryptography, backups and malware protection for mobile devices and also ensures that users receive appropriate training before they are issued with mobile devices. Users are required to accept in writing (DOC 11.5 and 11.6) specific responsibilities with regard to backups, malware protection and their use of mobile devices, particularly with regard to working in unprotected environments.

    11.7.2 Teleworking

    Is not permitted in the Trust Centre.

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

12. Information Systems

Information Systems Acquisition, Development & Maintenance

Control objective: to ensure that security is an integral party of information systems


PDF [29]12.1 Security Requirements of Information Systems

    12.1.1 Security requirements analysis and specification
    Statements of business requirements for new information systems, or enhancements to existing information systems, specify the requirements for security controls.
      12.1.1.1 The Organisation carries out a risk assessment (in line with DOC 4.4 [32], and see sub section 4.4 [32]) at the requirements stage of specifying any new information systems, or enhancements to existing systems (irrespective of whether they will be bespoke systems or commercial off the shelf systems). Required controls are identified and the [Head of Procurement] is responsible for ensuring that these controls are integrated into the [purchase decision], specification and purchase contract. The Information Security Manager is responsible for ensuing that required manual controls are designed and implemented.

      12.1.1.2 Application controls that ensure correct processing are also (where appropriate) considered at the design stage.

      12.1.1.3 Software is subject to testing and formal approval in line with DOC 10.10 [32]; non-compliant products are not accepted.

      12.1.1.4 The Organisation accepts products tested and evaluated in line with Appendix V.


12.2 Correct Processing in Applications

Control objective: to prevent errors, loss, unauthorized modification or misuse of information in applications

    12.2.1 Input data validation

    Data input to applications is provided from an external source and the responsibility of its accuracy is outside this ISMS.

    12.2.2 Control on internal processing

    Validation checks are incorporated into applications to detect any corruption of information through processing errors or deliberate acts.

    12.2.3 Message integrity

    Requirements for ensuring authenticity and protecting message integrity in applications have been identified, and appropriate controls identified and implemented

    12.2.4 Output data validation

    Data output from an application is validated to ensure that the processing of stored information is correct and appropriate to the circumstances


12.3 Cryptographic Controls

Control objective: to protect the confidentiality, authenticity or integrity of information by cryptographic means

    12.3.1 Policy on the use of cryptographic controls

    The Organisation has a policy on its use of cryptographic controls for protection of its information, as set out below

      12.3.1.1 The Organization applies cryptographic controls to secure its confidential communications and information carried beyond its secure logical perimeter, to secure connections from beyond its logical perimeter, and to secure its online business (as required in DOC 10.17 [32]). The Information Security Manager is responsible for maintaining DOC 12.1, which sets out, for each situation in which cryptographic controls are required under this policy, the type and length of the encryption algorithm required, and identifies the precise instructions required to use that cryptographic control. He is responsible for key management and [key generation as set out in DOC 12.1. Each asset Owner, whose information asset falls within the scope of this policy, is responsible for ensuring that the required cryptographic control is applied. The Information Security Manager is responsible for configuration of devices as required by this policy.

    12.3.2 Key management

    Key management, as documented in DOC 12.2, supports the Organization use of cryptographic techniques

    Control objective: to ensure the security of system files


12.4 Security of System Files

    12.4.1 Control of operational software

    The installation of software on operational systems is controlled by DOC 12.3

    12.4.2 Protection of system test data

    Test data is selected, protected and controlled in line with DOC 10.10 [32].

    12.4.3 Access control to program source code

    Access to program source code is restricted in line with DOC 10.15 [32]

12.5 Security in Development & Support Processes
Control objective: to maintain the security of application system software and information

    12.5.1 Change control procedures

    The implementation of changes is controlled by the use of the formal change control procedures set out in DOC 10.7.

    12.5.2 Technical review of applications after operating system changes

    When operating systems are changed, business critical applications are reviewed and tested in line with DOC 10.10 [32] to ensure there is no adverse impact on organisational operations or security.

    12.5.3 Restrictions on changes to software packages

    The Organisation does not seek bespoke modifications to commercial software packages.

    12.5.4 Information leakage

    Controls are applied to limit the opportunities for information leakage

      12.5.4.1 The Organisation regularly monitors personnel and system activities, as well as resource usage in computer systems, as described in sub section 5.1.1 [32] of this manual.

      12.5.4.4 Malware, that might give cause covert channels, is controlled through the anti-malware software (see 10.4 [32]) and User Agreements (see 11.2 [32] and 11.3 [32]).

    12.5.5 Outsourced software development

    The Organization does not outsource software development

12.6 Technical Vulnerability Management
Control objective: to prevent the damage resulting from exploitation of published technical vulnerabilities

    12.6.1 Control of technical vulnerabilities
      Timely information about technical vulnerabilities of information systems used by the Organisation is obtained, the Organisation’s exposure to those vulnerabilities evaluated, and DOC 12.4 sets out the measures taken to address the associated risks.

      Adlin Hisyamuddin
      Information Security Manager

      ____________________________

      On:

      08 November, 2007
      ____________________________

      Change history

      Issue 1 08 November, 2007 Initial issue

13. Information Security Incident Management

Control objective: to ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken.

PDF [29] 13.1 Reporting Information Security Events & Weaknesses

    13.1.1 Reporting information security events

    Information security events must be reported to the Information Security Manager as quickly as possible, as set out in DOC 13.1

    13.1.2 Reporting security weaknesses

    All employees, contractors and third party users of information systems and services are required by DOC 13.1 to note and report to the Information Security Manager any actual or suspected weaknesses in Organizational systems or services


13.2 Management of Information Security Incidents & Improvements

Control objective: to ensure a consistent and effective approach is applied to the management of information security incidents

    13.2.1 Responsibilities and procedures

    Management responsibilities and procedures have been established in DOC 13.2 to ensure a quick, effective and orderly response to information security incidents that ensures appropriate corrective or preventative actions, restores normal operations as quickly as possible, and ensures that improvement opportunities are identified and acted upon.

    13.2.2 Learning from information security incidents

    DOC 13.2 requires the Information Security Manager to quantify and monitor the types, volumes and costs of information security incidents.

    13.2.3 Collection of evidence

    In all information security incidents, irrespective of whether or not a follow-up action against a person or organization involves legal action (either civil or criminal), evidence is collected, retained and presented as set out in DOC 13.5 to conform to the rules for evidence laid down in the laws of the Kingdom of Bahrain.

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

14. Business Continuity Management

PDF [29]

14.1 Information Security Aspects of Business Continuity Management

Control objective: to counteract interruptions to business activities, to protect critical business processes from the effects of major failures of information systems or disasters and to ensure their timely resumption

    14.1.1 Including information security in the business continuity management process
    A managed process, set out in DOC 14.1, has been developed and is maintained for business continuity throughout the Organisation; it addresses the information security requirements needed for the Organisation’s business continuity

    14.1.2 Business continuity and risk assessment

    Events that can cause interruptions to business processes are identified as set out in DOC 14.2, along with the probability and impact of such interruptions, and the risk assessment process (DOC 4.4 [32]) is extended to apply to business continuity risks. These risk assessments drive the business continuity planning framework (DOC 14.3)

    14.1.3 Developing and implementing continuity plans including information security

    The Organisation’s Business Continuity Plan is developed in line with DOC 14.1 and is set out in DOC 14.3. It enables the Organisation to maintain or restore operations and ensure availability of information at the required level and in the required time scales following interruption to, or failure of, critical business processes

    14.1.4 Business continuity planning framework
    A single framework (as described in DOC 14.1) of business continuity plans is maintained to ensure that the plan and all its sub-plans are consistent, to consistently address information security requirements, and to identify priorities for testing and maintenance

    14.1.5 Testing, maintaining and re-assessing business continuity plans
    Business continuity plans are tested and updated regularly, in line with the requirements of DOC 14.4, to ensure that they are up to date and effective

    Shaikh Salman Mohammed Al-Khalifa Mohammed Al-Amer
    Director General of IT President of CIO

    ____________________________ _______________________________

    On:

    08 November, 2007
    ____________________________ _______________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

15. Compliance

Control objective: to avoid breaches of any law, statutory, regulatory or contractual obligations, and of any security requirements

PDF [29] 15.1 Compliance With Legal Requirements

    15.1.1 Identification of applicable legislation

    All relevant statutory, regulatory and contractual requirements and the Organization approach to meet these requirements have been explicitly defined, documented and are kept up to date for
    each information system and the Organization

      15.1.1.1 All contractual, statutory and regulatory requirements that apply to individual information assets are identified by the asset Owners (see sub section 7.1.2 [32]) and listed alongside the asset itself, in the asset inventory defined in accordance with sub section 7.1.1 [32] above.

      15.1.1.2 The Information Security Manager is responsible for creating and maintaining the schedule of the Organization statutory and regulatory information/data and computer-related compliance [3] requirements. The controls and responsibilities necessary to meet these compliance requirements are also identified in this schedule.

    15.1.2 Intellectual property rights
    Appropriate procedures have been implemented to ensure compliance with legislative, regulatory and contractual requirements on the use of material in respect of which there may be intellectual property rights and on the use of proprietary software products.

      15.1.2.1 The Organization has adopted a policy on intellectual property rights compliance which is set out in DOC 15.1.

      15.1.2.2 The Organization procedures to implement this policy are contained in DOC 15.3.

    15.1.3 Safeguarding of organizational records
    The Organization procedure, set out in DOC 15.2 protects important records from loss, destruction and falsification, in accordance with statutory, regulatory, contractual and business requirements

    15.1.4 Data protection and privacy of personal information
    Data protection and privacy are ensured as required and, where applicable, contractual clauses

      15.1.4.1 The Organization Data Protection and Privacy policy is set out in DOC 15.6.

      15.1.4.2 The Organization has appointed an Information Security Manager who is responsible for ensuring that the procedures set out in sub sections 15.4 and 15.5 are implemented.

      15.1.4.3 The Organization has implemented specific technical measures to protect personal information.

    15.1.5 Prevention of misuse of information processing facilities

    Users are be deterred from using information processing facilities for unauthorized purposes.

      15.1.5.1 Users are only allowed to access Organizational information facilities after they have signed a User Agreement (as required in DOC 11.2 [32]), in which they accept that disciplinary action may be commenced against anyone who abuses access rights or contravenes the Internet Acceptable Use Policy (DOC 7.2 [32]), the e-mail rules (DOC 7.3 [32]) or any other part of the ISMS. A warning about unauthorized access is also displayed at logon, as set out in DOC 11.9 [32].

      15.1.5.2 The Organization monitors compliance with these requirements, as described in DOC 7.4 [32] and DOC 10.18 [32].

    15.1.6 Regulation of cryptographic controls

    Cryptographic controls are used in compliance with all relevant agreements, laws and regulations, as set out in DOC 12.2 [32].


15.2 Compliance With Security Policies & Standards

Control objective: to ensure compliance of systems with organizational security policies and standards [10]

    15.2.1 Compliance with security policy and standards

    Managers ensure that all documented security procedures and work instructions within their area of responsibility are carried out correctly to achieve compliance with security policies and standards

      15.2.1.1 Managers are required, under their job descriptions, to carry out monthly checks to ensure that all security procedures and work instructions within their area of responsibility are being carried out, to identify shortfalls and to take action to ensure that shortfalls are immediately corrected. This action should involve identification of the causes of the non-compliance, an evaluation of the need for action to ensure non-recurrence of the shortfall, a determination of the appropriate action, followed by a review of the action to ensure that it has achieved its objectives. This follows the Organization PDCA approach.

      15.2.1.2 Managers are required to document these reviews in accordance with DOC 15.4 as well as the actions required, and responsibilities and timeframes, in the case of shortfalls.

      15.2.1.3 These management reviews and any actions arising must be reported in accordance with DOC 15.4 to the independent reviewers (see DOC 6.7 [32])

    15.2.2 Technical compliance checking

    Information systems are regularly checked for compliance with security implementation standards, and the Organization procedures for managing technical compliance checking are set out in DOC 15.4


15.3 Information Systems Audit Considerations

Control objective: to maximize the effectiveness of and to minimize interference to/from the information systems audit process

    15.3.1 Information systems audit controls

    Audit requirements and activities involving checks on operational systems are carefully planned as set out in DOC 15.5 and agreed with appropriate management to minimize the risk of disruptions to business processes.

    15.3.2 Protection of information systems audit tools
    Access to information systems audit tools are protected as required in DOC 15.5 to prevent any possible misuse or compromise


15.4 Compliance & Compliance Checking Procedure

The Organization’s entire ISMS is within the scope of this procedure.

Responsibilities

All personnel connected with the Trust Centre are responsible for ensuring and checking for procedural compliance.

The Information Security Manager is responsible for planning and commissioning technical compliance checking.

Procedure

Management review [ISO 17799 clause 15.2.1]

    15.4.3.1 On a monthly basis, the Information Security Manager will review operational conformance with those Organizational policies and procedures that apply to the information assets for which they are responsible/whose Owners report to them. Managers are not responsible for performing or commissioning technical compliance checking.

    15.4.3.2 The review must be reported/recorded on the Monthly Trust Centre Operational Report.

    15.4.3.3 Where a non-conformance is identified, the manager must determine the cause of the non-conformance, evaluate what action is required to ensure that the non-conformance does not re-occur, determine necessary corrective action (including obtaining any required authorizations) and take the identified action

    15.4.3.4 The details of the corrective actions, and confirmation of their successful implementation, should also be recorded in the [review report].

    15.4.3.5 Review reports are made available to independent reviewers carrying out independent reviews in line with DOC 6.7 [32].

    15.4.3.6 Managers are also responsible for identifying non-conformances in the ordinary course of business and taking appropriate corrective action appropriately.

    Technical Compliance Checking [ISO 17799 clause 15.2.2]

    15.4.4.1 The Information Security Manager has a schedule of the Organization’s information assets (gathered under DOC 7.1 [32]) and these are prioritized by their value to the Organization.

    15.4.4.2 All assets that are Risk Level 2 or above are checked for technical compliance with their documented configuration requirements as part of the monthly audit carried out by the Information Security Manager.

    ISO 27001 Auditor

    15.4.4.3 The Organization requires that any person/organization who carries out technical compliance checking has been either certified as an ISO 27001 Auditor or is an accredited WebTrust Compliance Auditor.

    15.4.4.4 The Information Security Manager approves the technical checking plan put forward by the ISO 27001 Auditor or WebTrust Compliance Auditor and authorizes commencement of the check plan only when satisfied that the testing will not compromise the asset or system being checked.

    15.4.4.5 Non conformances are identified and dealt with as described in Section 3, above.

    15.4.4.6 New weaknesses or vulnerabilities uncovered as a result of the technical compliance checking are reported in line with DOC 13.1 [32] and dealt with in line with DOC 13.2 [32].

    Systems Auditing Procedure

    The Organization’s information assets and whole ISMS are within the scope of this procedure.

    Responsibilities

    The Information Security Manager is responsible for planning systems audit activities. The Information Security Manager is responsible for authorizing audit activity to occur.

    Procedure [ISO 17799 clause 15.3.1]

    Audit controls

    The audit regime and the specific audit requirements will be documented and identified as part of the initial internal audit and will be identified and documented here, once completed. You should refer to the guidance of ISO 17799 clause 15.3.1 in drafting your procedure for this activity.

    Adlin Hisyamuddin
    Information Security Manager

    ____________________________

    On:

    08 November, 2007
    ____________________________

    Change history

    Issue 1 08 November, 2007 Initial issue

16. Change Management

PDF [29] The Information Security Manager is the Owner of this document and is responsible for ensuring that this policy document is reviewed in line with the review requirements stated above.

A current version of this document is available to all members of staff on request.

This manual was approved by the Board of the CIO Trust Centre on 08 November, 2007 and is issued on a version controlled basis under the signature of the Director General of IT.

Shaikh Salman Mohammed Al-Khalifa Mohammed Al-Amer
Director General of IT President of CIO

____________________________ _______________________________

On:

08 November, 2007 08 November, 2007
____________________________ _______________________________

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Issue 2 [issue date]

Issue 3 [issue date]

Issue 4 [issue date]


17. Appendix I – Contact List & Details

PDF [29] Operational Roles

1. Risk Assessment & PKI [30] Manager
Adlin Hisyamuddin
Information Security Manager, Head PKI
+973 1 772-6732
+973 3 986-7661
adlinh@cio.gov.bh [34]

2. Authorisation of Controls
Mubarak Abdulla Alhiddi
CSO/CIO

3 Change Initiation.
Ahmed Essa Abualfath
Computer Security Administrator
+973 1 772-6731
+973 3 968-7334
aabualfath@cio.gov.bh [35]

4 Change Management.
Shaikh Salman Mohammed Al-Khalifa
+973 3 968-9898
smalkhalifa@cio.gov.bh [36]

5 Network Management.
Khalid Al Othman
Chief, Network
+973 1 772-6325
+973 3 609-9167
osamarf@cio.gov.bh [37]

6 Network Administration.
Khalid Ali Al Jalahma
Network Administrator
+973 1 772-6729
kaljalahma@cio.gov.bh [38]

7 IT Operations.
Mohammed Al-Yassi
Director IT Operations

8 Software Development.
Sameh Abo-El-Ela
Development Manager

cssoshg@cio.gov.bh [39]
9 System Testing & Security Audit.
Osama Khalid Rafai
Computer Security Administrator
+973 1 772-6325
+973 36099167
osamarf@cio.gov.bh [37]

10 Employee Administration.
Hesham Al-Ghatam
Chief, Personnel & Admin’ Development
+973 1 787-8177
alghatamhe@cio.gov.bh [40]
Asset Purchase
11.
Khulood Al-Jassim
Supervisor Administration Service
+973 1 772-6760
aljassimk@cio.gov.bh [41]

12 Site/Secure Area Security Juffair.
Adel Khalifa Bu-Alai
Chief of Police in Juffair
+973 3 981-1055

13 Site/Secure Area Security Isa Town.
Mohammed Hamdan Mohammed
Chief of Police in Isa Town
+973 3 980-8096

Operational Controlling Roles
1. Digi-CA™ [2] Operating System Root Password Holders
Shaikh Salman Mohammed Al-Khalifa
+973 3 968-9898
smalkhalifa@cio.gov.bh [36]

Mohammed Al-Amer
President of CIO
+973 1 787-8101
+973 3 967-2222
malamer@cio.gov.bh [42]

2. Digi-CA™ Operating System Operation Password holders
Shaikh Salman Mohammed Al-Khalifa
+973 3 968-9898
smalkhalifa@cio.gov.bh [36]

Mubarak Abdulla Alhiddi
CSO/CIO

3. Digi-CA™ Operating System Administrators
Khalid Al Othman
Chief, Network
+973 1 772-6767
alothmank@cio.gov.bh [43]

Khalid Ali Al Jalahma
Network Administrator
+973 1 772-6729
kaljalahma@cio.gov.bh [38]

4. Master Digi-CA™ Administrator
Adlin Hisyamuddin
Information Security Manager
+973 1 772-6732
+973 3 986-7661
adlinh@cio.gov.bh [34]

Ahmed Essa Abualfath
Computer Security Administrator
+973 1 772-6731
+973 3 968-7334
aabualfath@cio.gov.bh [35]

5. Master Digi-CA™ Operator
Osama Khalid Rafai
Computer Security Administrator
+973 1 772-6325
+973 3 609-9167
osamarf@cio.gov.bh [37]

Khalid Ali Al Jalahma
Network Administrator
+973 1 772-6729
kaljalahma@cio.gov.bh [38]

6. Digi-CA™ RA Administrator
Saud Abdulaziz Bahzad
Smart Card Support
+973 3 903-3319
soudbah@cio.gov.bh [44]

Sameh Abo-El-Ela
Smart Card Technical
+973 1 772-6704
+973 3 6439376
cssoshg@cio.gov.bh [39]

7. Digi-CA™ Control Centre Operator

Isa Town Card Issuer No. 1 - to be selected by Adlin

Isa Town Card Issuer No. 2 - to be selected by Adlin

Key Ceremony Roles

1 Key Ceremony Administrator (& future Master of Ceremonies).
Adlin Hisyamuddin
Information Security Manager, Head PKI
+973 1 772-6732
+973 3 986-7661
adlinh@cio.gov.bh [34]

1. 1st Witness.
Osama Khalid Rafai - Computer Security Administrator
+973 1 772-6325
+973 3 609-9167
osamarf@cio.gov.bh [37]

3. 2nd Witness.
Elham Moh’d Saleh
Director Technical Resources
+973 17878017
elhama@cio.gov.bh [45]

4. Key Holder No. 1.
Shaikh Salman Mohammed Al-Khalifa
+973 3 968-9898
smalkhalifa@cio.gov.bh [36]

5. Key Holder No. 2.
Mubarak Abdulla Alhiddi
Senior Population Inspector – Supervisor
+973 39655366
monamj@cio.gov.bh [46]

6. Key Holder No. 3.,/h7>
Yousif Abdulla Ashoor
Senior Population Inspector – Clerk
+973 39457566
yashoor@cio.gov.bh [47]

7. Key Holder No. 4 - Ahmed Abdulmonem Alshami.
Ahmed Abdulmonem Alshami
Smart Card Support
+973 39537089
alshamyah@cio.gov.bh [48]

8. Key Holder No. 5 - Razan Abdulrahman Al Khalifa.
Razan Abdulrahman Al Khalifa
Smart Card Support
+973 39456565
razanaak@cio.gov.bh [49]

9. Member No.1 Security World.
Shaikh Salman Mohammed Al-Khalifa
+973 3 968-9898
smalkhalifa@cio.gov.bh [36]

10. Member No.2 Security World.
Mubarak Abdulla Alhiddi

11. Member No. 3 Security World.
Ahmed Al Mahmood
Director of Population Registry
+973 39672677
aalmahmood@cio.gov.bh [50]

13 Member No. 4 Security World.

14 Member No. 5 Security World.

HSM Configuration Roles

1. Key Ceremony Administrator (& future Master of Ceremonies)
Adlin Hisyamuddin
Information Security Manager, Head PKI
+973 1 772-6732
+973 3 986-7661
adlinh@cio.gov.bh [34]

2. 1st Witness.
Osama Khalid Rafai - Computer Security Administrator
+973 1 772-6325
+973 3 609-9167
osamarf@cio.gov.bh [37]

3. 2nd Witness.
Elham Moh’d Saleh
Director Technical Resources
+973 17878017
elhama@cio.gov.bh [45]

4. Member No.1 Security World.
Mubarak Abdulla Alhiddi

11. Member No. 3 Security World.
Ahmed Al Mahmood
Director of Population Registry
+973 39672677
aalmahmood@cio.gov.bh [50]

13. Member No. 4 Security World.

14. Member No. 5 Security World.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

17. Appendix II – Inventory of Assets, Suppliers & Authorities


PDF [29] Hardware


Date


Owner


Asset type


Make


Model


Serial No


Location


Classification


 Cost


Compliance
requirements


Security
Processes


CA (Inner Core) Safe Room


13/12/2006


 


Safe


Chubb


Europe

SN
77620

PKI DC


 


5000


 


OWI


20/12/2006


 


HSM


nCipher


netHSM
500


07-N55077M

PKI DC


 


11000


 


OWI


30/9/2007


 


HSM


nCipher


netHSM
500


SO-12-06-H002

PKI DC


 


11000


 


OWI


14/1/2007


 


Server
Rack


UK


APW

 

PKI DC


 


1238


 


OWI


01/01/2005


 


2
Network Points to inner Core


 


 

 

PKI DC


 


 


 


OWI


01/01/2005


 



Fire/Dust Sensors


Somke


Fire
Detectors

NA

PKI DC


 


120


 


OWI due
23/10/07


01/01/2005


 


Fire
Suppression System


Fike
SHP Pro Fire Alarm/Suppression Control System


FM 200
Gas

341861.2

PKI DC


 


15000


 


OWI due
23/10/07


01/01/2005


 


Air
Conditioning from Main Aircon


Clivet


VR-DX
71


FLStDmCZ0A

PKI DC


 


20000


 


OWI due
23/10/07


01/12/2006


 


Backup
air conditioning unit


YOKO



LD-24CS/A1

HKA
1135

PKI DC


 


300


 


OWI due
23/10/07


01/01/2005


 


Light
Fitting & switches


 


 

 

PKI DC


 


 


 


OWI


01/12/2006


 


Door
Exit Switch


Alpro


NA

NA

PKI DC


 


2000


 


OWI due
23/10/07


13/12/2006


 


Door
Latch


Trimec


TS2001

NA

PKI DC


 


456


 


OWI due
23/10/07


CA (Inner) Core


08/01/2007


 


Server


Dell


PE2950
Xeon 5160

CBXGK2J

PKI DC


 


1814


 


OWI


08/01/2007


 


Server


Dell


PE2950
Xeon 5160

9WCHK2J

PKI DC


 


1814


 


OWI


08/01/2007


 


Server


HP



Proliant HP 380


CZC7262Q6B

PKI DC


 


1814


 


OWI


08/01/2007


 


Server


HP



Proliant HP 381


CZC7263523

PKI DC


 


1814


 


OWI


13/12/2006


 


Switch


Cisco



Catalyst2960


F0C1041X2G4

PKI DC


 


817


 


OWI


13/12/2006


 



Firewall



TippingPoint


X505


Zuz96E00009904

PKI DC


 


13973


 


OWI


 


 


KBM
Keyboard


N/C


N/C

N/C

N/C


N/C


N/C


N/C


N/C


 


 


KBM
Switch


N/C


N/C

N/C

N/C


N/C


N/C


N/C


N/C


01/01/2005


 


2
Network Points to Safe Room


 


 

 

PKI DC


 


 


 


OWI


01/01/2005


 


2
Network Points to Main Juffair Fibre


 


 

 

PKI DC


 


 


 


OWI


01/01/2005


 


2
Network Points to outer Core


 


 

 

PKI DC


 


 


 


OWI


13/12/2006


 


Server
Rack


UK


APW

47170

PKI DC


 


1238


 


OWI


13/12/2006


 


Server
Rack


UK


APW

47166

PKI DC


 


1238


 


OWI


01/01/2005


 


Fire
Suppression System


Fike
SHP Pro Fire Alarm/Suppression Control System


FM 200
Gas

341861.2

PKI DC


 


15000


 


 


01/01/2005


 



Fire/Dust Sensors


Somke


Fire
Detectors

NA

PKI DC


 


15000


N/C


N/C


13/12/2006


 


Motion
Sensor


Texecom


Mirage
Pro-Quad

NA

PKI DC


 


33


 


 


01/01/2005


 


Light
Fitting & switches


 


 

 

PKI DC


 


 


 


OWI


01/01/2005


 


Air
Conditioning from Main Aircon


Clivet


VR-DX
71


FLStDmCZ0A

PKI DC


 


20000


 


 


01/01/2005


 


Backup
air conditioning unit


YOKO



LD-24CS/A1

HKA
1272

PKI DC


 


300


 


 


13/12/2006


 


CCTV
Camera



Infinova



V1481L-36A15

63121040

PKI DC


 


285


 


 


13/12/2006


 


Door
Exit Switch


Alpro


NA

NA

PKI DC


 


2000


 


 


13/12/2006


 


Door
Latch


Trimec


TS2001

0

PKI DC


 


456


 


 


CA Outer Core (Admin)


13/12/2006


 


Access
Control to Safe Room


Identix


V20 UA
HTLV20P-5K

390600348

PKI DC


 


2520


 


 


13/12/2006


 


Access
Control CA Inner Core Room


Identix


V20 UA
HTLV20P-5K

30700024

PKI DC


 


2520


 


 


13/12/2006


 


Access
Control to Unner Core


Identix


V20 UA
HTLV20P-5K

500303254

PKI DC


 


2520


 


 


13/12/2006


 


DVR



Infinova



V3010/4L

61210298

PKI DC


 


477


 


 


01/12/2006


 


Remote
Control


 


 

 

PKI DC


 


25


 


 


13/12/2006


 


Monitor



Infinova



V1322/14

6300145

PKI DC


 


117


 


OWI


01/12/2006


 


Coaxial
cables


 


 

 

PKI DC


 


 


 


OWI


13/12/2006


 


PC


Acer


Veriton
2800


PS280D5601647000495W

PKI DC


 


405


 


OWI


00/01/1900


 



Keyboard


Acer



Keyboard


TH097YRD371711A22532

PKI DC


 


35


 


OWI


00/01/1900


 


Mouse


Acer


Mouse


3892A378

PKI DC


 


10


 


OWI


13/12/2006


 


Monitor


Acer


AC713B


ESC04080345220024FPK11

PKI DC


 


125


 


OWI


13/12/2006


 


Switch


SMC



EZSWITCH 8 Port


SMSFS8EUA

PKI DC


 


 


 


OWI


13/12/2006


 


Door
Latch


Trimec


TS2001

NA

PKI DC


 


456


 


 


13/12/2006


 


Exit
switches


ALPRO


NA

NA

PKI DC


 


88


 


 


13/12/2006


 


Power
supply


 


12V 5
amps

NA

PKI DC


 


116


 


OWI


13/12/2006


 


Alarm
Control Panel


Veritas


Excel

NA

PKI DC


 


74


 


 


13/12/2006


 


LCD
Keypad


Texecom


Premier
LCD Keypad

NA

PKI DC


 


50


 


 


13/12/2006


 


Dialer


Texecom


Speech
Dialler

NA

PKI DC


 


63


 


 


13/12/2006


 


Siren


Texecom


Odyssey
1

NA

PKI DC


 


18


 


 


13/12/2006


 


CCTV
Cameras



Infinova



V1481L-36A15

63121034

PKI DC


 


285


 


 


14/12/2006


 


Fully
Funtional Telephone



Panasonic



KX-T2375JXW


5CAOD062187

PKI DC


 


 


 


 


13/12/2006


 


Access
Control CA Main Entrance


Identix


V20 UA
HTLV20P-5K

 

PKI DC


 


2520


 


 


13/12/2006


 



Emergency lights


Khind


EM2004G


R2-042234

 


 


 


 


 


External


13/12/2006


 


Server
Rack


UK


APW

0

Juffair


 


1238


 


OWI


08/01/2007


 


Server


Dell


PE2950
Xeon 5160

41WHK2J

Juffair


 


1814


 


OWI

08/01/2007


13/12/2006


 


Switch


Cisco



Catalyst2960


F0C1041X2G4

Juffair


 


817


 


OWI


13/12/2006


 



Firewall



TippingPoint


X505


Zuz96E00009904

Juffair


 


13973


 


OWI


 


 


KBM
Keyboard


 


 

 

Juffair


 


 


 


OWI


 


 


KBM
Switch


 


 

 

Juffair


 


 


 


OWI


01/01/2005


 


Network
Points (itemise ( in& out))


 


 

 

Juffair


 


 


 


OWI


01/01/2005


 


Fire
Suppression System


EMI
Fire Alarm System


AFA
MINERVA System 2100

NA

Juffair


 


 


 


 


01/01/2005


 



Fire/Dust Sensors


EMI
Fire Alarm System


Fire
Detectors

NA

Juffair


 


 


 


 


01/01/2005


 


Light
Fitting & switches


 


 

 

Juffair


 


 


 


 


01/01/2005


 


Air
Conditioning from Main Aircon


Denco
Miller


DM5

NA

Juffair


 


 


 


 


01/01/2005


 


Backup
air conditioning unit


Pearl



EG024FCAC

800390

Juffair


 


 


 


 

The Information Security Manager is the owner of this document and is responsible for ensuring that it is maintained by the relationship owners

This document was issued by the Information Security Manager on 08 November, 2007 and is issued on a version controlled basis.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Software


Date


Owner


Asset type


Make


Model


Serial No


Location


Classification


 Cost


Compliance
requirements


Security
Processes


CA (Inner Core) Safe Room


14/01/2007


 


OS


Microsoft


Windows Server 2003


1


PKI DC


 


 


 


 


20/09/2007


 


OS


RedHat


Enterprise Linux 5


3


PKI DC


 


 


 


 


07/10/2007


 


Digi-CA™


Digi-Sign


Xp


1


PKI DC


 


97,000


 


 


CA (Inner) Core


14/01/2007


 


Access Control


Identix


4.6.1.0


1


PKI DC


 


 


 


 


14/01/2007


 


CCTV control


Infinova


V.1.00.09


1


PKI DC


 


 


 


 


14/01/2007


 


OS


Microsoft


XP Pro


1


PKI DC


 


 


 


 


15/01/2007


 


AntiVirus


Trend Micro


OfficeScan 8.0


1


PKI DC


 


 


 


 


CA Outer Core (Admin)


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


External


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Juffair


20/09/2007


 


OS


RedHat


Enterprise Linux 5


2


PKI DC


 


 


 


 



 



 


SMTP


Microsoft


Exchange 2003


1


Juffair



 



 



 



 



 



 


DNS (*.gov.bh)


RedHat


Enterprise Linux 4


1


Juffair



 



 



 



 



 



 


DNS (*.gdn)


Microsoft


Windows Server 2003


1


Juffair



 



 



 



 

The Information Security Manager is the owner of this document and is responsible for ensuring that it is maintained by the relationship owners

This document was issued by the [Information Security Manager] on [date] and is issued on a version controlled basis.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Intangible


Date


Owner


Asset type


Make


Model


Serial No


Location


Classification


Compliance
requirements


Security
Processes


CA (Inner Core) Safe Room


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


CA (Inner) Core


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


CA Outer Core (Admin)


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


External


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Juffair


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 

The [Information Security Manager] is the owner of this document and is responsible for ensuring that it is maintained by the relationship owners

This document was issued by the [Information Security Manager] on [date] and is issued on a version controlled basis.

Signature: Date:

Authorities & Suppliers



Owner


Organization


Function


Address


Contact


Telephone


e-mail


Web

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The [Information Security Manager] is the owner of this document and is responsible for ensuring that it is maintained by the relationship Owners

This document was issued by the [Information Security Manager] on [date] and is issued on a version controlled basis.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

External Parties: Information Security Procedure

1 Scope
According to DOC 6.8 [32] / DOC 6.8 [32] of this Manual, the Organization maintains the security of its information processing facilities and information assets in relation to external parties. All external parties who need to access any Organizational information assets are subject to this procedure. The Organization has (or may have) external party agreements with the following categories of organizations, all of whom are covered by this procedure; risks may be assessed for external parties as individual organizations or as categories, depending on the level of risk involved:
a) Service providers
b) Managed security services
c) Customers
d) Outsourcing suppliers (facilities, operations, IT systems, data collection, call centres, others)
e) Consultants and auditors
f) Developers and suppliers of IT systems and services
g) Cleaning, catering and other outsourced support services
h) Temporary personnel, placement and other (casual) short-term appointments

2 Responsibilities
2.1 All relationship Owners (see sub section 7.1.2 [32] of the Manual) responsible for services in any of the above categories are required to ensure that external parties have entered into a formal external party agreement under this procedure and that transitions (of information, information processing facilities, and any other information assets or personnel) are planned and executed without a reduction in the level of security that existed prior to commencement of the transition.
2.2 Relationship Owners are responsible for ensuring that the security controls, service definitions and delivery levels included in external party agreements are implemented, maintained and operated by the external party.
2.3 The Information Security Manager is responsible for carrying out risk assessments (see DOC 4.4 [32]) where required by this procedure.

3 Procedure [ISO 17799 sub section 6.2]
3.1 Where there is a business need for working with external parties, the Organization ensures that its information security is not reduced; access to Organizational assets is not granted until a risk assessment (DOC 4.4 [32]) has been completed, appropriate controls identified and implemented.

4 Risk Identification [ISO 17799 clause 6.2.1]
4.1 The Organization carries out a risk assessment (in line with the requirements of procedure DOC 4.4 [32]) to identify risks related to external party access.

4.2 The risk assessment identifies (in addition to the requirements of DOC 4.4 [32]) and documents, for each external party:
a) The information processing facilities and information assets the external party will access;
b) The type of access the third party will have – physical access and/or logical access (identifying the assets that will be accessed), whether the access is taking place on-site or off-site and the exact location from which access will be made;
c) The value and classification (see sub section 7.2 [32] of the Manual) of the information that will be accessed;
d) The information assets that the external party are not intended to access and which may required additional controls to secure;
e) The external party’s personnel (see sub section 8.1 [32] of the Manual), including their contractors and partners, who will or might be involved;
f) How external party personnel are to be authenticated (see Section 11 [32] of the Manual);
g) How the external party will process, communicate and store information;
h) The impact to the external party of access not being available when required, or of inaccurate or misleading information being entered, received or shared;
i) How the Organization’s information security incident management procedure (see Section 13 [32] of the Manual) will be extended to incorporate information security incidents involving the external party;
j) Any legal, regulatory or other contractual issues that should be taken into account with respect to the external party;
k) How the interests of other stakeholders might be affected by any decisions.

5 Controls are selected in line with the requirements of DOC 4.3 [32].

6 The Organization implements those controls that are within its own power, and in line with the requirements of sub section 3.2 of the Manual (the DO phase). [32]

7 The Organization agrees with the external party those controls that the external party is required to implement and documents them in an agreement (drawn up by the Organization’s legal advisers) that the third party signs. The obligations on the external party include ensuring that all its personnel are aware of their obligations.

8 The agreements between the Organization and external parties (whether suppliers or customers) are created by the Organization’s legal advisers, who are required to specifically include or provide documented reasons for excluding any of the items on the checklist below, and the requirement for which may have been identified through the risk assessment, from any such contract:
a) The information security policy (sub section 5.1.1 of the Manual);
b) The controls identified as required through the risk assessment process (see
4 [32]), which may include procedures and technical controls;
c) A clear definition and/or description of the product or service to be provided, and a description of information (including its classification) to be made available;
d) Requirements for user and administrator education, training and awareness (see sub section 8.2.2 [32] of the Manual);
e) Provisions for personnel transfer;
f) Description of responsibilities regarding software and hardware installation, maintenance and de-commissioning;
g) Clearly defined reporting process, reporting structure, reporting formats, escalation procedures and the requirement for the external party to adequately resource the compliance [3], monitoring and reporting activities;
h) A specified change management process (see sub section 10.1.2 [32] in the Manual);
i) Physical controls, including secure perimeters (see Section 9 [32] of the Manual);
j) Controls against malware (see sub section 10.4 [32] of the Manual);
k) Access control policy (see Section 11 [32] of the Manual);
l) Information security incident management (see Section 13 [32] of the Manual) and agreement violation management procedures;
m) The target level for service and security, unacceptable service and security levels, definition of verifiable performance and security criteria, monitoring and reporting;
n) The right to monitor and audit performance (including of the third party’s processes for change management, vulnerability identification and information security incident management), to revoke activities, and to use external auditors;
o) Service continuity requirements;
p) Liabilities on both sides, legal responsibilities and how legal responsibilities (including data protection and privacy) are to be met;
q) The protection of IPR and copyright;
r) Controls over any allowed sub-contractors;
s) Conditions for termination/re-negotiation of agreements, including contingency plans.

9 Information exchange agreements [ISO 17799 clause 10.8.2]

o9.1 Additional controls must (subject to an individual risk assessment in relation to each proposed agreement) be considered where the contract is for the exchange of information or software:
9a) the specific management responsibilities and procedures on each side for notifying transmission, dispatch and receipt and any specific controls associated with each action;
10b) procedures to ensure non-repudiation and to ensure traceability;
11c) the required standards [10] for packaging (see DOC 9.12 [32]) and means of transmission;
12d) The agreed labelling system (see DOC 7.6);
13e) Courier selection and identification methods (see DOC 9.12 [32]);
14f) Escrow agreements (where applicable);
15g) How information security incidents (loss of or damage to an information asset in transit) will be managed;
16h) Data protection, copyright, software licensing (see sub section 15.1 [32] of the Manual);
17i) Any technical standards that be required for recording or reading software or information;
18j) Any other special controls, such as cryptography (see sub section 12.3 [32] of the Manual).

-10 Managing changes to third party services [ISO 17799 clause 10.2.3]

o10.1 The Organization may need to agree changes to external party contracts and agreements to take account of changes that it makes to, or as a result of:
oa) the services it currently offers to its clients;
ob) new applications and systems it has developed or acquired;
oc) modifications, changes or updates to its own policies and procedures;
od) new or amended controls arising from new risk assessments or information security incidents.

o10.2 The external party may need to request changes to the contract in order to implement:
oa) changes or improvements to their networks or other infrastructure;
ob) new or improved technologies, new products or new releases of current products;
oc) new development tools, methodologies and environments;
od) new physical locations or physical services;
oe) new vendors or other suppliers of hardware, software or services.

o10.3 Any changes that may be required are subject to a new risk assessment (taking into account the criticality of the business systems involved) and review of the selected controls (see clauses 4.1 [32] and 5 [32]).
o10.4 New controls, or changes to existing controls are identified, authorized, agreed with the third party, and made the subject of an agreed variation to the existing contract. This must be clearly documented and signed off by both parties.
o10.5 The relationship Owner is responsible for ensuring that the revised controls are implemented and incorporated into the existing review and monitoring arrangements.

The Information Security Manager is the owner of this document and is responsible for ensuring that this procedure is reviewed in line with the review requirements of the ISMS.
A current version of this document is available to PKI team members of staff on the corporate intranet.

This procedure was approved by the Information Security Manager on 08 November, 2007 and is issued on a version controlled basis under his signature

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue


17. Appendix III - Operating Work Instructions [OWIs]

HSM OWI

PDF [29] Scope:

The purpose of this document is to provide full Operating Work Instructions for the use, maintenance and support of the HSM in place at CIO

Responsibility & Asset Ownership:

[Please Indicate – probably Information Security Manager] is responsible for ensuring that this OWI is fully implemented and regularly updated to reflect any changes in the environment at CIO. As per the asset list the {Indicate – probably Information Security Manager] is the owner of the assets covered in this OWI.

Details of the Operating Work Instruction:

1. The business specification and user requirements (usability and user friendliness) for the system

The nCipher net HSM is a hardware platform for providing cryptographic services to enhance the security of a variety of applications - from PKI [30] and authentication systems to Web services and SSL protected communications. The net HSM acts as a network-attached resource for secure cryptographic processing, providing an alternative deployment scenario to the traditional approach of dedicated HSMs on individual servers. By allowing multiple servers to securely access a single HSM to perform cryptographic functions, overall equipment costs can be reduced and system management simplified. Whilst dedicated HSMs are appropriate for security applications and servers that demand guaranteed availability and/or processing power, many deployments encompass multiple servers, either in a single site or across a wide
geographic area, where a shareable, network connected HSM is a perfect solution.

The CIO uses the nCipher HSM device (herein referred to as “HSM”) to securely generate and store the private keys for the CAs it operates.

The HSM device has been designed to remove any daily administration responsibilities from the administering users. The daily administration duties of the HSM device are reduced to a minimum and are internally performed by a self automated system management control mechanisms, that reside inside the HSM device. On a scheduled basis, CIO users appointed as administrators of the HSM device, are required to inspect the HSM operations by checking the log report accessible on the front panel screen of the HSM device.

The daily operating duties of the HSM are limited to the cryptographic signing operations and on periodic basis, the HSM device may be used by the CIO to generate fresh cryptographic keys when a new CA [4] is created. In the event of a new CA creation, the generation of new private keys is performed in a secure environment, video recorded, documented, witnessed and notarized thus assuring, that highest security is in place.

The device has a text based interface provided through the flat screen residing on the front panel of the HSM device.

All features and functionalities provided by the HSM device are documented and described in the hardware installation, administration and operation manuals available to CIO personnel.

2. The operational efficiency of the system - i.e. does it deliver the business benefits expected of it?

Since this is a hardware device, no maintenance is required to keep the device in an ongoing operational state. The supplied hardware documentation available to CIO personnel describes all features and functionalities provided by the HSM device, including installation guides, configuration instructions and error correction.

3. Basic implementation guide for the system (where does it sit on the IT, ICT or electric network (connectivity wise), how users are set-up, administration console, basic maintenance and back up (see below), disaster recovery functionality (if applicable)

The HSM device is located in the CIO’s highly secured data centre: ISA Town, which has two independent power supply sources, one from an external power supplier and the second from the CIO’s internal power generator. The power provided to the HSM device is isolated from other power segments inside the data centre building, thus meeting the independency and failover requirements in the event of any power failure or circuit overload.

The HSM deployment architecture includes a multi two HSM devices configured for High Availability. This mechanism balances the usage of network and hardware resources between two HSM devices and thus provides greater system performance and fail over support. The diagram below illustrates the current CIO’s deployment architecture of the Digi-CA™ [2] PKI System, with which the two HSM devices have been configured for operation:

Both HSM devices are placed in a dedicated, CISCO firewall/switch protected network segment. The CA core network in ISA Town, to which the HSMs are connected, is isolated from other corporate networks inside CIO and physical access to the Inner and Outer Core rooms as presented on the above diagram, is strictly protected with biometric devices and video camera monitoring performed 24 hours per day throughout the entire year.

The HSM devices, which are located in the Inner Core room inside the ISA Town Data Centre building, are the central cryptographic operation processing units for the CA System deployed inside CIO. Each HSM is connected to a dedicated back-end server hosting the relevant CA System components and both of the back-end servers have been configured for High Availability and provide a failover mechanism to the operation of CA System. The HSM provides the following main functionalities:

  • Hardware Configuration
  • Security World Management
  • Operator Card Set Management
  • Key Generation
  • Key Management
  • Log reporting
  • Backup

Each of the above functionalities is documented in the hardware manual available to CIO administering and operating personnel.

4. The identified acceptance criteria
The installation and configuration of the HSM devices inside the CIO has been completed with the accordance to the hardware installation manual available to the CIO personnel. The manual provides a step by step instruction set allowing the administering users to correctly install and configure an HSM device. Upon successful installation of each device, a manual device operation check was run by the administering user to ensure the device has been installed and configured correctly and is up and running. For this purpose, a HSM support toolkit provided by the device vendor was used. Before the system was switched into a production environment, a set of test private keys was generated to ensure the HSMs are operating correctly. After each test, the HSM log was inspected to verify whether each operation was accomplished correctly.

The set of testing operations for CA AMC included:

    1 Initializing the device.
    2 Creating new Security World.
    3 Logging to the HSM device.
    4 Accessing all HSM features.
    5 Registering new Operator Card Set.
    6 Generating private keys.
    7 Using private keys to sign digital data.
    8 Inspecting HSM log.

All operations have been performed with the accordance to the hardware administration and operation manual available to CIO personnel.

5. The Organization's performance requirements and current capacity

CIO expects Digi-CA™ HSM to store up to 100 private keys of either 1024 bits, 2048 bits or 4096 bits size and sign around 100 000 Digital Certificates [14] in total, provided the current deployment architecture and allocated hardware capacity for the CA System. The maximum number of digital certificates issued per day will not reach 10 000. The CA System deployment architecture is expected to support 24/7/365 availability and currently there is no requirement for CIO to have an online disaster recovery centre. In an event of an irrecoverable major system or hardware failure, all disaster recovery activities will be carried out manually by the CIO appointed administering personnel, by recreating the CA System environment or loading configuration to a HSM device from backup resources. The above performance requirements have been measured, confirmed and tested by the CA System software and HSM hardware vendors and they meet the CIO requirements stated above.

6. Methods of error recovery, system restart and contingency plans

The HSM device provides extended system operation control mechanisms, that automatically raise an alert when a critical exception error is encountered during the operations of the device. The alert is immediately logged in the HSM log. The HSM log is accessible to CIO appointed administering users from the flat screen residing on the front panel of the device or from the operating system command prompt of the server connecting to the HSM device. All exception error log entries are reported by HSM device using a unique error number and associated descriptive text, that informs the inspecting user about the type of the error and why it was generated. This architecture provides CIO administering users with an easy mechanism for identifying the source for the error and allows immediate correction of the problem. For irrecoverable or unidentified errors, CIO administering users should contact the hardware vendor to obtain further assistance.

7. Methods of testing the systems routine operating procedures (and, where appropriate, manual procedures) to defined and agreed standards [10]

The HSM administering users should perform regular inspections of HSM log to verify the correctness of its operations.

To ensure, that HSM devices are not vulnerable to any attacks or exploits, CIO appointed administering personnel should perform a weekly CA System network scans searching for possible new vulnerabilities.

The CISO network devices used inside the CA System network, such as firewalls and switches are equipped with network Intrusion Detection Systems [IDS], which constantly monitor all network traffic within the CA System network and immediately alert all administering users in an event of an intrusion attempt. These devices are configured by default to automatically disable any connectivity for a potential attacker. Administering users should additionally analyze the IDS reports on a weekly basis to attempt to identify any suspicious communication directed to any of the CA System Services or HSM devices.

8. The set of required security controls (for the systems and in terms of any impact on the overall organization) that were identified at project initiation

Physical access to the CA System core location, where HSM devices are placed, should be protected with biometrics and should be divided into multiple access points excluding the existence of a single access point. CIO has assigned its secure Data Centre in ISA Town to install both HSM devices. This location provide security guarding of the building entrance, camera monitoring of entire building, biometric access to Data Centre IT operations rooms and book logging for all entries and exists.

Network access to the CA System, where HSM devices reside, is divided into two general segments: public and private. While the public segment can be accessed by any one through Internet, private segment is strictly secured for internal communications only and disabled for external access. In the CIO deployment architecture of the CA System, public access is allowed only to the Services located in the Juffair Data Centre building and it includes RA Registration Service, Time-Stamping [17] Service and OCSP [16] Service. The HSM devices are accessible only to the CSP Service installed on two dedicated back-end servers residing in the Outer Core room inside the ISA Town Data Centre building. For authentication purposes, hardware cryptographic devices are installed on each of the back-end servers to ensure that no other server can connect to any of the HSM devices. All communication to the HSM devices is encrypted using strong cryptography standards and a cryptographic authentication mechanisms are in place to ensure that only authorized Services can access the HSM device resources.

9. Methods of testing for covert channels and Trojans

The HSM devices use industry standard cryptography, encryption mechanisms and hardware cryptographic devices for secure communications, such as AES encryption and nCipher nToken PCI devices, therefore ensuring, that no man-in-the-middle attack can succeed and no unauthorized party can obtain sensitive data or spoof the identity of the accessing Service. The operating core of the CA System, where HSMs are located, is isolated from any external networks such as Extranets or Internet and access to HSM devices is only possible after successful authentication using strong cryptographic mechanisms. Leaving the devices with no write-access from Internet or any external networks, makes enough protected against unwanted application and computer viruses circling throughout the Internet. The physical and network isolation of the HSM devices along with strict network access control policies in place, significantly reduce the possibility of an injection of a computer virus or an application commonly referred to as a Trojan Horse. Given the architecture of the device, it is not possible to inject any third party application code without prior cryptographic authentication to the device.

10. Business continuity arrangements (as you know this is to simply rebuild a new environment, but we need an outline of the cause & affects)

The CIO currently does not require an online disaster recovery solution and relies on multi service High Availability configuration of the CA System and failover configuration of two HSM devices. In an event of a failure of one HSM device, a second device will be used instead.

In an event of irrecoverable failure, the HSM devices will either be re-initialized or replaced with new hardware and system environment will be rebuild from scratch and HSM configuration data will be restored from the most recent backup stored on a dedicated backup server. The HSM hardware manual documents the process of hardware installation and CIO administering personnel should refer to the manual for instructions related to hardware installation and recovery from a major HSM failure.

The reinstallation and recovery of the HSM device should take no more than 48 hours. During the outage period Digital Certificates issued by the CA System, which uses the HSM devices, will remain valid and therefore the event will not affect the business continuity of the CIO nor will it cause any damage to End Entities to whom certificates are issued.

11. Interactions with other systems, to ensure that the new system will not adversely affect existing systems, including in capacity requirements

The preliminary calculation of device capacity utilization of the was performed by the CIO during the project initialization phase and therefore a sufficient capacity and hardware resources were allocated to the CA System upon installation, allowing the HSM hardware to continue an uninterrupted operations utilizing the necessary capacity for around 100 private keys and signing around 100 000 digital certificates in total. During the maintenance period, CIO appointed administering users will inspect the hardware performance logs once per 6 months and produce a report based on which the CIO will decide whether an additional hardware resource allocation or hardware replacement is required.

The hardware, network and physical location resources dedicated for the CA System have been completely separated by the CIO from any of its other network and application layer segments. Both HSM devices, that the CA System is using, are solely dedicated to the operation of the CA infrastructure and therefore do not interact nor interfere with any other network and software solutions, applications and facilities deployed inside CIO. The operations of the HSM devices does not have any technical impact on any of the areas of the CIO’s daily operations.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Digi-CA OWI

Scope:

The purpose of this document is to provide full Operating Work Instructions for the use, maintenance and support of the Digi-Ca in place at CIO

Responsibility & Asset Ownership:

[Please Indicate – probably Information Security Manager] is responsible for ensuring that this OWI is fully implemented and regularly updated to reflect any changes in the environment at CIO. As per the asset list the {Indicate – probably Information Security Manager] is the owner of the assets covered in this OWI.

Details of the Operating Work Instruction:

1. The business specification and user requirements (usability and user friendliness) for the system

Digi-CA™ PKI System (herein referred to as: “CA System”) is the complete Certificate Authority [CA] system deployed inside Central Informatics Organization [CIO], which required to have its own CA to provide enhanced communication security and identity assurance to its own organization and to Bahraini Citizens. The CA System issues the Digital Certificates, in conformance with RFC 3280 standard, that are used by the CIO personnel and Bahraini Citizens for two factor authentication, electronic signatures and email protection. The CA System also issues Digital Certificates, that are used by the CIO to introduce client-to-device and device-to-device authentication using public key cryptography.

The CIO uses CA System to create multiple instances of unique CAs in a single CA System installation. The Digi-CA™ model imposes delegation of trust downwards from Root CAs to their Subordinate Certification Authorities [Sub-CAs]. The same installation of Digi-CA™ also enables any of these CAs to be cross signed by an external third party CA and any number of CAs can have any number of cross signed Subordinate CAs. This CA model is a requirement for CIO, which intends to deliver unique CA services to various governmental departments inside the Kingdom of Bahrain and to the Bahraini Citizens.

The daily administration duties of the CA System are reduced to a minimum and are internally performed by a self automated system management control mechanisms, that reside inside the CA System. On a scheduled basis, CIO users appointed as administrators of the CA System, are required to inspect the CA System operations by checking the log report and the service status report, which are both accessed through a web based CA Administration Management Console [CA AMC] or alternatively can be viewed directly from the Operating System command prompt console.

The daily operating duties of the CA System are limited to the issuance, revocation or suspension of Digital Certificates to the requesting entities, Bahraini Citizens, government institutions or CIO personnel. CIO users appointed as Registration Authority [RA] Operators can issue, revoke, suspend and de-suspend digital certificates by accessing a web based RA Management Console [RA MC] GUI.

All features provided by GUI management interfaces of the CA system, such as CA AMC and RA MC consoles, are logically grouped and easy to access upon successful authentication through an intuitive graphical menu. The CIO users appointed as administrators and operators, can easily access relevant console features without having great prior knowledge of PKI technology or CA System architecture.

The software manual provided by the CA System software vendor delivers the necessary documentation needed to administer and operate the CA system. CIO users should refer to this manual to identify the meaning of all CA System and individual console functionalities, the scope of their administering and operating responsibilities as well as deployment and configuration guidelines.

2. The operational efficiency of the system - i.e. does it deliver the business benefits expected of it?

The maintenance of the CA System has been made easy to perform by the software vendor to an extend where a non technical personnel, having basic understanding of the software manual, can perform the necessary activities to correctly maintain the system to allow its uninterrupted operations. Daily duties of CIO users appointed as system administrators have been reduced to weekly inspections of the correct system operations. The necessary administering activities can be performed on a weekly basis by an authenticated personnel only, using a web based CA AMC GUI, through which users can view status reports of various CA System services and inspect the CA System logs to verify the correctness of its operations. All reporting information produced by the CA System provides a unique identifying number for a reported event as well as its intuitive and easy to understand textual description. The log reporting feature introduces different type of log entries, therefore it is easy for the CIO personnel to distinguish log entries between informational messages, critical errors and warning alerts. This enables CIO personnel with the ability to correctly inspect the system operations and troubleshoot any errors encountered during the CA System operations.

The CA System clearly distinguishes the roles and responsibilities of individual users, therefore administering the system is explicitly separated from the operating activities, which do not require from the appointed CIO personnel any technical knowledge related to the CA System administration as well as any knowledge in cryptography or Public Key Infrastructure industry standards. By following processes driven by the CA System, operating users can easily issue, revoke, suspend and de-suspend digital certificates. All administering and operating procedures are clearly documented in the CA System manual provided by the software vendor.

3. Basic implementation guide for the system (where does it sit on the IT, ICT or electric network (connectivity wise), how users are set-up, administration console, basic maintenance and back up (see below), disaster recovery functionality (if applicable)

The Digi-CA™ PKI System software suite is a multi application component based PKI system for managing cryptographic keys, Digital [X.509] Certificates and supplemental PKI related services. Each application component (herein referred to as “Service”) provides a series of defined functionalities to other PKI application components of the system, as well as to administering and operating parties, as well as to end entities, to whom certificates are issued. This CA System is built with the following modules:

a. CA Application Server [CA APS]
b. Cryptographic Service Provider [CSP]
c. Time-Stamp Gateway Server [TSA Gateway]
d. Online Certificate Status Protocol Gateway Server [OCSP Gateway]
e. CA Administration Management Console [CA AMC]
f. Registration Authority [RA] Management Console [RA MC]
g. Registration Authority [RA] Registration Service [RA RS]
e. CA Database Server [CA DB]

All of the CA System components are located in the CIO’s highly secured data centres: ISA Town and Juffair, which both have two independent power supply sources, one from an external power supplier and the second from the CIO’s internal power generator. The power provided to the CA System is isolated from other power segments inside the data centre buildings, thus meeting the independency and failover requirements in the event of any power failure or circuit overload.

The CA System deployment architecture includes a multi server Service distribution model for each PKI application component provided by the CA System. This mechanism balances the usage of network and hardware resources between several server devices and thus provides greater system performance and fail over support. The diagram below illustrates the current CIO’s deployment architecture of the Digi-CA™ PKI System:

Each Service of the CA System is placed in a dedicated, CISCO firewall/switch protected network segment. The CA core network in ISA Town is isolated from other corporate networks inside CIO and physical access to the Inner and Outer Core rooms as presented on the above diagram, is strictly protected with biometric devices and video camera monitoring performed 24 hours per day throughout the entire year.

The CA Administration Management Console [CA AMC], which is installed on two dedicated back-end servers located in the Outer Core room inside the ISA Town Data Centre building, is a central CA management panel GUI for CIO users appointed as CA Administrators and CA Operators. The two back-end server hosting the CA AMC has been configured for High Availability and provide a failover mechanism to the operation of CA AMC component. The console provides the following main functionalities:

  • PKI Service status reporting

  • Administrative Account [User] management

  • Certification Authority Account [CA] management

  • Registration Authority Account [RA] management

  • Registration and management of PKI application components [Services]

  • X.509 Digital Certificate Profile management

  • Authorization of Administration Tasks

  • Management of system logs and log archiving

  • Console Language Setup

  • CA System Backup management

  • CA System Software upgrade

  • CA AMC Console configuration

Each of the above functionalities is documented in the CA System manual available to CIO administering and operating personnel.

The RA Management Console [RA MC], which is installed on a dedicated front-end server located in the Outer Core room inside the ISA Town Data Centre building, is a central RA management panel GUI for CIO users appointed as RA Administrators and RA Operators. The front-end server hosting the RA MC provides the first point of access for the RA Operations Centre, from where RA Administrators and RA Operators can access the console features. This Service has been also installed on two front-end servers, configured for High Availability, located inside the Juffair Data Centre building, to provide – if necessary - a failover support as a second access point for the RA Operations Centre, from where RA Administrators and RA Operators can access the console. The RA MC console provides the following main functionalities:

  • Administrative Account [User] management

  • Digital certificate utilization reporting

  • Issuance of digital certificate

  • Digital certificate revocation

  • Digital certificate suspension

  • Digital certificate de-suspension

  • Console Language setup

  • Authorization of Operation Tasks

  • Activity Log management

  • Time-Stamping Service and User management


Each of the above functionalities is documented in the CA System manual available to CIO administering and operating personnel.

The RA Registration Service [RA RS], which is installed on a dedicated front-end server located in the Outer Core room inside the ISA Town Data Centre building, is a central panel GUI for certificate subscribers [End Entities], to whom digital certificates are issued. The front-end server hosting the RA RS provides the first point of access for the RA Operations Centre, from where End Entities can access the Service features. This Service has been also installed on two front-end servers, configured for High Availability, located inside the Juffair Data Centre building, to provide second access point for End Entities, who can access the Service through the Internet. The RA RS console provides the following main functionalities:

  • New Digital Certificate Application

  • Digital Certificate Revocation

  • Digital Certificate Suspension

  • Digital Certificate De-Suspension

  • Digital Certificate Renewal

  • Digital Certificate Status Check

Each of the above functionalities is documented in the CA System manual available to CIO administering and operating personnel.

The CA Application Server, which is installed on two dedicated back-end servers located in the Outer Core room inside the ISA Town Data Centre building, is an internal module of the CA system and is self-operated, meaning it does not provide or require any user management or user access functionalities. Only a CIO appointed administering personnel acting as the operating system super user can stop or start this service. The Service is registered by the administering user through the CA AMC. This Service can be accessed only by another CA System Service, that was previously registered within the CA system.

Cryptographic Service Provider is an internal module of the CA system, which is installed on two dedicated back-end servers, configured for High Availability, located in the Outer Core room inside the ISA Town Data Centre building. This Service is self-operated and does not provide or require any user management or user access functionalities. Only a CIO appointed administering personnel acting as the operating system super user can stop or start this Service. The Service is registered with the CA System by administering user through the CA AMC. This Service is not accessible to any user or other Service of the CA System.

Time-Stamp Service Gateway Server is a user accessible Service of the CA System, which is installed on two dedicated front-end servers, configured for High Availability, located in the Juffair Data Centre building. This Service is self-operated and does not provide or require any user management functionalities. It however authenticates, using a username and password, all individual subscribed users being the Citizens of Bahrain or any other Time-Stamping Service subscribed users against the CA Database before access to the Service can be provided to the user. Only a CIO appointed administering user acting as the operating system super user can stop or start this Service. The Service is registered with the CA System by the administering user through the CA AMC. This Service has been designed to be accessed by public Internet community as well as by CIO personnel.

Online Certificate Status Protocol Gateway Server is a user accessible Service of the CA System, which is installed on two dedicated front-end servers, configured for High Availability, located in the Juffair Data Centre building. This Service is self-operated and does not provide or require any user management functionalities. It however provides an open access to end users requiring OCSP service, as defined in the RFC 2560 standard. This Service has been designed to be accessed by public Internet community as well as by CIO personnel.

The CA Database is a SQL based database server, which is installed on two dedicated back-end servers, configured for High Availability, located in the Outer Core room inside the ISA Town Data Centre building. This Service is self-operated and provides the central storage facility for CA System managed data. Access to the CA DB resources is possible only to authenticated Services of the CA System and to the CIO appointed personnel acting as the super user of the operating system, who can access database for low level operations from the operating system command prompt. Each Service or administering user accessing the database resources must pass two factor authentication [13]:

  • using a username and password
  • using private and public cryptographic keys for SSL Client Authentication


The CA DB does not store any security critical data such as CA or End Entity private cryptographic keys and therefore it is not considered as a critical security point in the overall architecture of the deployed CA System. The CA DB data is backed up regularly on a daily basis and the backup data is automatically stored on a dedicated backup server residing in the ISA Town Data Centre building.

4. The identified acceptance criteria.

The installation of the CA System inside the CIO has been completed with the accordance to the software installation manual available to the CIO personnel. The manual provides a step by step instruction set allowing the administering users to correctly install and configure each of the CA System Services. Upon successful installation of each Service, a manual Service operation check was run by the administering user to ensure the Service has been installed correctly and is up and running. For this purpose, the Service Status Reporting of the CA AMC was used. Before the system was switched into a production environment, a set of test activities were performed to ensure entire CA System is operating correctly. After each test, the CA System log was inspected to verify whether each operation was accomplished correctly.

The set of testing operations for CA AMC included:

1. Logging to the CA AMC
2 Accessing all CA AMC features
3. Registering new Services (RA MC, RA RS, CA APS, TSA, OCSP)
4. Inspecting Service Status Report
5. Creating new Administrative Accounts
6. Creating new CA Accounts
7. Creating new RA Accounts
8. Inspecting CA System log

The set of testing operations for RA MC included:

1 Logging to the RA MC.
2 Inspecting certificate utilization report.
3 Creating new Digital Certificate.
4 Creating a multiple number of Digital Certificates in a batched process.
5 Creating new Time-Stamping Service users.
6 Inspecting Activity log.

The set of testing operations for RA RS included:

1 Accessing the RA RS.
2 Requesting new Digital Certificate.
3 Revoking a Digital Certificate.
4 Suspending a Digital Certificate.
5 De-suspending a Digital Certificate.
6 Installing a Digital Certificate on an End Entity computer.
7 Installing a Digital Certificate on an End Entity Cryptographic Hardware Device.

Test set of testing operations for CA APS in combination with Time-Stamping Gateway included:

1 Requesting a Time-Stamp Token.
2 Verifying the Service response.

Test set of testing operations for CA APS in combination with OCSP Gateway included:

1 Requesting an OCSP response.
2 Verifying the Service OCSP response.

All operations have been performed with the accordance to the CA System manual available to CIO personnel.

5. The Organization's performance requirements and current capacity

CIO expects Digi-CA™ System to issue around 100 000 Digital Certificates in total, provided the current deployment architecture and allocated hardware capacity. The maximum number of digital certificates issued per day will not reach 10 000. The CA System deployment architecture is expected to support 24/7/365 availability and currently there is no requirement for CIO to have an online disaster recovery centre. In an event of an irrecoverable major system failure, all disaster recovery activities will be carried out manually by the CIO appointed administering personnel, by recreating the CA System environment from backup resources. The above performance requirements have been measured, confirmed and tested by the CA System software vendor and they meet the CIO requirements stated above.

6. Methods of error recovery, system restart and contingency plans.

The CA System provides extended system operation control mechanisms, that automatically raise an alert when a critical exception error is encountered during the operations of any of the system Services. The alert is immediately logged in the CA System log and delivered through an SMTP messaging system to all registered administering users. The CA system log is accessible to CIO appointed administering users from a web based management console [CA AMC] or from the operating system command prompt. All exception error log entries are reported by CA System using a unique error number and associated descriptive text, that informs the inspecting user about the type of the error, the Service that generated it and the line of the application code, at which the error has occurred. This architecture provides CIO administering users with an easy mechanism for identifying the source for the error and allows immediate correction of the problem. For irrecoverable or unidentified errors, CIO administering users should contact the software vendor to obtain further assistance.

7. Methods of testing the systems routine operating procedures (and, where appropriate, manual procedures) to defined and agreed standards

The CA System administering users should perform regular inspections of CA System log to verify the correctness of its operations.

To ensure, that CA System Services are not vulnerable to any attacks or exploits, CIO appointed administering personnel should perform a weekly CA System network scans searching for possible new vulnerabilities.

The CISO network devices such used inside the CA System network, such as firewalls and switches are equipped with network Intrusion Detection Systems [IDS], which constantly monitor all network traffic within the CA System network and immediately alert all administering users in an event of an intrusion attempt. These devices are configured by default to automatically disable any connectivity for a potential attacker. Administering users should additionally analyze the IDS reports on a weekly basis to attempt to identify any suspicious communication directed to any of the CA System Services.

8. The set of required security controls (for the systems and in terms of any impact on the overall organization) that were identified at project initiation

Physical access to the CA System core location should be protected with biometrics and should be divided into multiple access points excluding the existence of a single access point. CIO has assigned its secure Data Centre in ISA Town and Juffair to host the CA System. Both locations provide security guarding of the building entrance, camera monitoring of entire building, biometric access to Data Centre IT operations rooms and book logging for all entries and exists.

Network access to the CA System is divided into two general segments: public and private. While the public segment can be accessed by any one through Internet, private segment is strictly secured for internal communications only and disabled for external access. In the CIO deployment architecture of the CA System, public access is allowed only to the Services located in the Juffair Data Centre building and it includes RA Registration Service, Time-Stamping Service and OCSP Service. The remaining Services of the CA System are using strong cryptography standards for encrypting the communication from User-to-Service as well as Service-to-Service and a cryptographic authentication mechanisms are in place to ensure that only authorized identities can access relevant system resources.

9. Methods of testing for covert channels and Trojans

The CA System uses industry standard cryptography and encryption mechanisms for secure communications, such as Secure Socket Layer [51] and Transport Layer Security protocols between Service, therefore ensuring, that no man-in-the-middle attack can succeed and no unauthorized party can obtain sensitive data or spoof the identity of the accessing user or device. The operating core of the CA System is isolated from any external networks such as Extranets or Internet and access to individual CA System Services is only possible after successful authentication using strong cryptographic mechanisms, such as SSL Client Authentication. Leaving the system with no write-access to Internet or any external networks, makes enough protected against unwanted application and computer viruses circling throughout the Internet. The physical and network isolation of the CA System along with strict network access control policies in place, significantly reduce the possibility of an injection of a computer virus or an application commonly referred to as a Trojan Horse.

10. Business continuity arrangements (as you know this is to simply rebuild a new environment, but we need an outline of the cause & affects)

The CIO currently does not require an online disaster recovery solution and relies on multi service High Availability configuration of the CA System. Each of the CA System Services has been distributed to two dedicated servers configured for High Availability to enable support for failover in an event of a failure of one server.

In an event of irrecoverable failure, the CA System will be rebuild from scratch and configuration and database data will be restored from the most recent backup stored on a dedicated backup server. The CA System software manual documents the process of system installation and CIO administering personnel should refer to the manual for instructions related to system installation and recovery from a major system failure.

The reinstallation and recovery of the entire CA System should take no more than 48 hours. During the outage period Digital Certificates issued by the CA System will remain valid and therefore the event will not affect the business continuity of the CIO nor will it cause any damage to End Entities to whom certificates are issued.

11. Interactions with other systems, to ensure that the new system will not adversely affect existing systems, including in capacity requirements

The preliminary calculation of drive capacity utilization of the CA System was performed by the CIO during the project initialization phase and therefore a sufficient capacity and hardware resources were allocated to the CA System upon installation, allowing it to continue an uninterrupted operations utilizing the necessary capacity for around 100 000 digital certificates. During the maintenance period, CIO appointed administering users will inspect the utilization process of the drive capacity and hardware resources once per 6 months and produce a report based on which the CIO will decide whether an increase of the drive capacity or additional hardware resource allocation or hardware replacement is required.

The hardware, network and physical location resources dedicated for the CA System has been completely separated by the CIO from any of its other network and application layer segments. All hardware and software components, that the CA System is using, are solely dedicated to its operation and therefore do not interact nor interfere any other network and software solutions, applications and facilities inside CIO. The operations of the CA System does not have any technical impact on any of the areas of the CIO’s daily operations.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Monitors, Mouse & Keyboards, KBMs, Coaxial Cables & Network Points OWI

Scope:

The purpose of this document is to provide full Operating Work Instructions for the use, maintenance and support of the Monitors, Mice and Keyboards in use within the framework of the PKI CA.

Responsibility & Asset Ownership:

The Network Manager is responsible for ensuring that this OWI is fully implemented and regularly updated to reflect any changes in the environment at CIO. As per the asset list the Network Manager is the owner of the assets covered in this OWI.

Details of the Operating Work Instruction:

A. Monitors

Monitors are to be plugged into a PC or Server for which it has been allocated (cross referenced in the asset list). Monitors should be switched to power saving mode when not used.

Monitors are to be kept clean of dust and users may not leave drink or food beside monitors.

Monitors are not under warranty. No specific support contract is in place to replace monitors within agreed periods of time should the monitor become faulty. [SUPPLIER] can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network Manager whether it might be appropriate to unplug a monitor used in another machine (PC or Server) to plug it back into the machine whose assigned monitor is faulty. When replacement units are delivered and implemented, existing units should be returned to their original place. Any such decision and associated action must be documented and signed off by the Information Security Manager and the Network Manager.

Monitors may not be taken out of the CA rooms without prior approval from the information security manager under any circumstances whatsoever.

B. Mouse

CIO use a number of various models of “mouse”. Each mouse is to be plugged into a PC or Server for which it has been allocated (cross referenced in the asset list).

Each mouse is to be kept clean of dust and users may not leave drink or food beside mouse.

No mouse is under supplier warranty. No specific support contract is in place to replace mouse units within agreed periods of time should they become faulty. [SUPPLIER] can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network Manager whether it might be appropriate to unplug a mouse used in another machine (PC or Server) to plug it back into the machine whose assigned mouse is faulty. When replacement units are delivered and implemented, existing units should be returned to their original place. Any such decision and associated action must be documented and signed off by the Information Security Manager and the Network Manager.

Mouse units may not be taken out of the CA rooms without prior approval from the information security manager under any circumstances whatsoever.

C. Keyboard

CIO use a number of various models of keyboards. Each keyboard is to be plugged into a PC or Server for which it has been allocated (cross referenced in the asset list).

Each keyboard is to be kept clean of dust and users may not leave drink or food beside keyboards.

Keyboards are not under supplier warranty. No specific support contract is in place to replace keyboards within agreed periods of time should they become faulty. [SUPPLIER] can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network Manager whether it might be appropriate to unplug a keyboard used in another machine (PC or Server) to plug it back into the machine whose assigned keyboard is faulty. Once replacement units are delivered and implemented, existing units should be returned to their original place. Any such decision and associated action must be documented and signed off by the Information Security Manager and the Network Manager.

Keyboards may not be taken out of the CA rooms without prior approval from the information security manager under any circumstances whatsoever.

Please note that anti-spyware software approved by the Information Security Manager must be ran on the network at least [once a month] to ensure that no keyloggers are present on the network as this could compromise the overall security of the PKI infrastructure.

D. KBM

CIO use KBMs to allow one monitor to be used for a number of designated server(s) or PC(s). Each KBM is to be plugged into the PCs or Servers for which it has been allocated (cross referenced in the asset list).

Each KBM is to be kept clean of dust and users may not leave drink or food beside keyboards.

KBMs are not under supplier warranty. No specific support contract is in place to replace them within agreed periods of time should they become faulty. [SUPPLIER] can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network manager whether it might be appropriate to plug monitors directly into a PC or server. Once replacement units are delivered and implemented, existing units should be returned to their original place. Any such decision and associated action must be documented and signed off by the Information Security Manager and the Network Manager. When replacement units are delivered and implemented, existing units should be returned to their original place.

KBMs may not be taken out of the CA rooms without prior approval from the information security manager under any circumstances whatsoever.

E. Coaxial Cables & Network Points

CIO use coaxial cables and network points as referenced in the Asset List. These items are not under supplier warranty. No specific support contract is in place to replace them within agreed periods of time should they become faulty. [SUPPLIER] can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network manager whether it might be appropriate interchange Coaxial Cables or Network Points (where applicable). Once replacement units are delivered and implemented, existing units should be returned to their original place. Any such decision and associated action must be documented and signed off by the Information Security Manager and the Network Manager. When replacement units are delivered and implemented, existing units should be returned to their original place.

Cables and Network Points may not be taken out of the CA rooms without prior approval from the Information Security Manager under any circumstances whatsoever.

Additional Notes pertaining to the Operational Working Instructions:

Keyboards, Monitors and Mouse units are delivered by vendors with users manuals either with dedicated Sections related to each asset or with a full users manual allowing for customization of the configuration. Where applicable such manuals are available in the manuals folder.

Other than at the initial installation stage, no specific testing of the assets is required. Basic performance criteria consist in making sure that monitors, keyboards and mouse units function properly and allow interaction with the PC(s) or server(s) these assets are allocated to.

No specific training is provided to users in relation to the assets covered in this OWI as most users intuitively know how to use basic functionality.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Switch Catalyst 2960 OWI

Scope:

The purpose of this document is to provide full Operating Work Instructions for the use, maintenance and support of the Switch Catalyst 2960 in use within the framework of the PKI CA (namely for PKI DC and Juffair).

Responsibility & Asset Ownership:

The Network Manager is responsible for ensuring that this OWI is fully implemented and regularly updated to reflect any changes in the environment at CIO. As per the asset list the Network Manager is the owner of the assets covered in this OWI.

Details of the Operating Work Instruction:

A. Integration and Initial Set-up

The Cisco Switch Catalyst 2960 should be implemented using the guidelines of the software guidance guide produced by Cisco. The switch is configured using Cisco command line access.

Switches are line between machines and a network access point the unit needs to be powered up and is already working in transparent mode.

The unit can be configured either by using CLI (Command Line Interface). All of the following needs to be fully configured:

Initial Configuration and Settings

The switch is configured to 4 different subnets:

Subnet 1
10.10.19.0/26
10.10.19.1 – First IP
10.10.19.63 – Broadcast

Subnet 2
10.10.19.64/26
10.10.19.65 – First IP
10.10.19.127 – Broadcast

Subnet 3
10.10.19.128/26
10.10.19.129 – First IP
10.10.19.191 – Broadcast

Subnet 4
10.10.19.192/26
10.10.19.193 – First IP
10.10.19.255 - Broadcast

Performance Features

  • Intelligent features at the network edge, such as sophisticated access control lists (ACLs) and enhanced security
  • Dual-purpose uplinks for Gigabit Ethernet uplink flexibility, allowing use of either a copper or a fibre uplink-each dual-purpose uplink port has one 10/100/1000 Ethernet port and one Small Form-Factor Pluggable (SFP)-based Gigabit Ethernet port, with one port active at a time
  • Network control and bandwidth optimization using advanced QoS, granular rate limiting, ACLs, and multicast services
  • Network security through a wide range of authentication methods, data encryption technologies, and NAC based on users, ports, and MAC addresses
  • Easy network configuration, upgrades, and troubleshooting using Cisco Network Assistant software
  • Autoconfiguration for specialized applications using Smartports
  • Limited lifetime hardware warranty
  • Software updates at no additional charge

Policy and Configuration Instructions:

The Network Manager in co-operation with the Information Security Manager decides on the policy implemented on the Cisco Switch Catalyst appliances. The policy is then implemented and saved with a back-up of the latest policy to saved in CIO Juffair to allow for Disaster Recovery purposes.

Item Policy Rule Description Justification
1 Switch Authentication Rule User Authentication at Switch User Management to guarantee confidentiality

The policy which is implemented must be fully documented and updated on a regular basis within this document.

Alert Escalations and IOS Updates:

The Cisco Switch Catalyst 2960 allows the Network Administrator to create rules for alerts to be a configured to be sent to either the Network Manager and the Information Security Manager. CIO to include details of escalation rules here-switch is transparent, no logging, escalation rules.

Update of the Cisco IOS must be done regularly and performed by the Network Manager as and when the latest IOS for the switch is made available from Cisco; must be agreed with the Information Security Manager and IT Operations Manager.

CISCO IOS Software Release 12.2(25)SEB.

In terms of performance monitoring, the Cisco Switch 2960 should be ample for the requirements of CIO at present. However should service be degraded and performance be impacted CIO should review the logs of the Cisco Catalyst 2960 to check that the bandwidth and performance capabilities of the units are not maxed out. If so configuration might be changed or a requirement for a clustered Cisco Catalyst environment to improve performance should also be envisaged, to be decided by the Network Manager and Information Security Manager to be submitted for approval according to the rules of this ISMS.

B. Subscription and Advance Replacement Instructions:

Cisco Catalyst 2960 units are covered under subscription with Fakhro Electronics with 1 year warranty. This ensures that the IOS version is regularly available for updates. Fakhro Electronics can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network Manager whether it might be interchange Cisco 2960s or to use a third party Switch to continue operations instead of the original Cisco Catalyst 2960. When replacement units are delivered and implemented, the configuration of the original unit must be implemented and tested as per the initial implementation. All associated actions must be documented and signed off by the Information Security Manager and the Network Manager.

Additional Notes pertaining to the Operational Working Instructions:

The Cisco Catalyst 2960 units are to be kept clean of dust and users may not leave drink or food beside the appliances.

Cisco Catalyst 2960 units may not be taken out of the CA rooms without prior approval from the information security manager under any circumstances whatsoever.

Cisco Catalyst 2960 units are delivered by vendors with users manuals either with dedicated Sections related to each asset or with a full users manual allowing for customization of the configuration. The main reference guide for the Cisco 2960 is entitled Catalyst 2960 Switch
Software Configuration Guide. CIO uses all the best practice guidelines available for these units in the guide. The guide is included in the series of manuals which are available in the manuals folder.

No specific training is provided to users in relation to the assets covered in this OWI as most users intuitively know how to use basic functionality. However CIO have a number of Cisco trained professionals to CCNA levels which allows CIO to perform a number of administration duties with internal staff and without requiring external assistance.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Tipping Point X505 OWI

Scope:

The purpose of this document is to provide full Operating Work Instructions for the use, maintenance and support of the Tipping Point X505 in use within the framework of the PKI CA (namely for PKI DC and Juffair).

Responsibility & Asset Ownership:

The Network Manager is responsible for ensuring that this OWI is fully implemented and regularly updated to reflect any changes in the environment at CIO. As per the asset list the Network Manager is the owner of the assets covered in this OWI.

Details of the Operating Work Instruction:

F. Integration and Initial Set-up

The Tipping Point hardware firewall and IPS appliance(UTM) is easy to install and very intuitive to set-up. Once plugged in line between a switch and a network access the unit needs to be powered up and is already working in transparent mode.

The Tipping Point Unit can support mixed environments irrespective of topology or IP addressing scheme. We have implemented the following mode of the UTM:

- NAT (including Virtual Server and PAT)

The UTM is configured with the following:

Interface 1 – External (Connected to CIO Isa Town main core switch)

Interface 2 – Frontend (Connected to Switch Subnet 2)

Interface 3 – Backend (Connected to Switch Subnet 3)

Interface 4 – HSM (Connected to Switch Subnet 4)

Tipping Point testing is carried out initially to ensure that the solution works transparently and allows legitimate traffic through and does show in its logging interface the number of attacks being stopped or simply logged. Each type of attack will generate an alert which can be sent via multi channel such as SMS or e-mail to the Network Manager and/or Information Security Manager.

Policy and Configuration Instructions:

The Network Manager in co-operation with the Information Security Manager decides on the policy implemented on the Tipping Point appliances. The policy is then implemented and saved with a back-up of the latest policy to be saved in CIO Juffair to allow for Disaster Recovery purposes.

The units allow for the following features to be implemented.

User Set-up

The Network manager will set-up accounts for themselves and the Information Security Manager.

Client and Server Protection

  • Prevent attacks on vulnerable applications and operating systems

  • Eliminate costly ad-hoc patching

  • Multi-mode attack blocking Digital Vaccine Real-Time Protection

  • Pre-emptive protection against threats

  • Automatic distribution of latest filters

  • Recommended Settings

Spyware and Peer-to-Peer Protection

  • Protect clients from becoming infected with spyware
  • Prevent walk-in-worms (from infected laptops), from uploading data to the network
  • Block or rate limiting Peer-to-Peer and Instant Messaging applications

Multiple Security Zones

  • Separate levels of policy enforcement:

    • Departmental subnets

    • Corporate DMZs

    • Student/teacher networks

    • Time-of-day based privileges


Flexible Policy Engine

  • Object-based policy rules:

  • Network/security zone/IP address group-
    Time-of-day based privileges

  • Service application

  • Schedules/time of day

  • VPN tunnels

Unified control of multiple services:

  • Web filtering

  • Traffic shaping

  • User authentication

  • Device administration

Encryption and Authentication

  • Next-generation IPSec encryption,
    including hardware-accelerated DES, 3DES,
    and AES

  • X.509 Digital Certificate authentication from internal or third-party certificate authorities

  • Web-based user authentication

On-box and external RADIUS database
URL Filtering

  • Configurable allow/deny URL lists

  • Regular-expression URL matching

Web Content Filtering

Annual subscription includes:

  • 40 content categories

  • Unlimited URL listings

TippingPoint Isa Town

Item Policy Rule Description Justification
1 Deny all services Firewall is set to deny all access for all services to any servers behind it. Allows only specific traffic through the network.
2 Spyware turned on Allows to protect CIO against known Spyware attacks Spyware could compromise the Integrity and availability of CIO PKI CA
3 X.509 Digital Certificate authentication
from internal or third-party certificate
authorities Allows CIO to ensure that certificates created by Digi-CA are let through the Tipping Point Allows for secure communication of CA certs to relevant parties
4 Intrusion Prevention System/Intrusion Detection System Detects and prevents intrusion from all attacks. Blocks and prevents any other attacks not blocked by firewall

TippingPoint Firewall Juffair

Item Policy Rule Description Justification
1 Deny all services Firewall is set to deny all access for all services to any servers behind it. Allows only specific traffic through the network.
2 Spyware turned on Allows to protect CIO against known Spyware attacks Spyware could compromise the Integrity and availability of CIO PKI CA
3 X.509 Digital Certificate authentication
from internal or third-party certificate
authorities Allows CIO to ensure that certificates created by Digi-CA are let through the Tipping Point Allows for secure communication of CA certs to relevant parties
4 Intrusion Prevention System/Intrusion Detection System Detects and prevents intrusion from all attacks. Blocks and prevents any other attacks not blocked by firewall

The policy which is implemented must be fully documented and updated on a regular basis within this document.

Secure Management and & Alert Escalations:

The TippingPoint X505 is supported by the TippingPoint Security Management System (SMS), an enterprise-class management platform, which provides intuitive management for multiple TippingPoint IPS or X505 devices. The TippingPoint SMS arrives with factory-installed software for simplistic installation. CIO use the standard web based configuration so that the Network manager can perform installation and maintenance routine tasks and to allow the Information Security Manager to access the logs and policy where applicable.

The SMS is to be used to create rules for alerts to be a configured to be sent to either the Network Manager [NM] and the Information Security Manager [ISM]. Currently the rules are not agreed and the NM & ISM have identified this as a risk that will be addressed, documented and provided in this Manual in time for the second update of the manual on 14 November, 2007

The X505 is configured to send email notification when a High Level alert is detected by it.

Red Hat Isa Town

Item Issue Escalation patch Action Item / Remediation
1 Red(High Priority Alert) – can be from Intrusion Detected, Worm outbreak, etc. Send alert to Network Manager Integrity Checks to be ran on CIO network

Red Hat Juffair

Item Issue Escalation patch Action Item / Remediation
1 Red(High Priority Alert) – can be from Intrusion Detected, Worm outbreak, etc. Send alert to Network Manager Integrity Checks to be ran on CIO network

CIO to complete tables for each implementation PKI DC and Juffair. Information included in the example shown is for guidance purposes only.

In terms of performance monitoring, the Tipping Point x505 should be ample for the requirements of CIO at present. However should service be degraded and performance be impacted CIO should review the logs of the Tipping Point to check that the bandwidth and performance capabilities of the units are not maxed out. If so configuration might be changed or a requirement for a clustered Tipping environment to improve performance should also be envisaged, to be decided by the Network Manager and Information Security Manager to be submitted for approval according to the rules of this ISMS.

Subscription and Advance Replacement Instructions:

Tipping Point is covered under subscription with Fakhro Electronics with 1 year subscription. This ensures that the database of attacks for which Tipping Point scans is fully up to date. Fakhro Electronics can be contacted as per the details on the suppliers register to organize replacement unit(s). In the meantime, users may decide in conjunction with the Information Security Manager and Network Manager whether it might be appropriate to continue operations without Tipping Point Protection. When replacement units are delivered and implemented, the configuration of the original unit must be implemented and tested as per the initial implementation. All associated actions must be documented and signed off by the Information Security Manager and the Network Manager.

Additional Notes pertaining to the Operational Working Instructions:

The Tipping Point units are to be kept clean of dust and users may not leave drink or food beside the appliances.

Tipping Points units may not be taken out of the CA rooms without prior approval from the information security manager under any circumstances whatsoever.

Tipping Point units are delivered by vendors with users manuals either with dedicated Sections related to each asset or with a full users manual allowing for customization of the configuration. Where applicable such manuals are available in the manuals folder.

Full activity and log reports are available out of the box for Tipping Point and should be produced on a monthly basis by the Network Manager and sent to the Information Security Manager for review. Should the Information Security Manager request changes to the policy this must be done in accordance to the change control procedure.

No specific training is provided to users in relation to the assets covered in this OWI as most users intuitively know how to use basic functionality.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Motion Detector, Alarm, Power Supply & Siren OWI

Operating Work Instructions – Alarm Control Panel, Speech Dialler, Siren, Power supply, LCD Keypad and Motion Sensors

Scope:

This document covers the Operating Work Instructions for the Alarm Control Panel, Dialer, Siren, Power supply and LCD Keypad located throughout the datacenter in Isa Town.

Responsibilities:

The safe is the responsibility of the Physical Security Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. Alarm Control Panel is Veritas Excel.
a. 12 zones panel, 2 partitions, 32 user codes, 4 outputs relay modules, 8 programmable outputs with 12 V battery for backup
2. Speech Dialler is Texecom Speech Dialler.
a. 32 character LCD display, 4 voice message(each up to 32 seconds), 8 voice message, 4 trigger input
3. Siren is Texecom Odyssey 1 and is mounted on the outside wall of Isa Town’s Computer Room.
4. Power supply is Yuasa NP2.8-12 12V 2.8AMP Battery to provide backup power in case of power failure to the Alarm Control Panel.
5. LCD Keypad is Texecom Premier LCDL Keypad
a. Remote keypads with standard 32 character LCD display and a speaker driver unit for programmable volume control, surface mount
6. The motion sensors are Texecom Mirage Pro-Quad Q-Logic Movement sensors.
7. All the sensors are connected to the alarm control panel.
8. To ARM the alarm: PRESS
and FULL button.
9. To RESET the alarm: PRESS <4 digit access code> and RESET button.
10. As part of the PKI Data centre construction project, all the items mentioned above have a 2 year warranty and support from Mantech from the date of handover.
11. Security:
a. The access code for the alarm is held by Physical Security Section personnel only and is changed regularly.
b. The alarm has a 20 second window from alarm is armed OR when an intruder detected inside the Data centre.
c. If the access code is failed to be entered in 20 seconds, the siren on the outside of the building will sound and flash. The speech dialler will then call the numbers stored in memory in the following order:
i. Physical Security Personnel 1
ii. Physical Security Personnel 2
iii. Head of PKI
iv. CA Administrator
d. The dialler will keep on dialling the numbers above in order until it is answered.
12. Emergencies:
a. In case of failure, contact Mantech 17730459.
.
Ownership:

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Backup Air Conditioning Unit OWI

Scope:

This document covers the Operating Work Instructions for the Backup Air Conditioning Unit located throughout the PKI Data centre in Isa Town.

Responsibilities:

The backup air conditioning unit is the responsibility of the PKI Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. The backup air conditioning units to be used in case of failure of the main air conditioning unit or when the temperature in the data centre is not of suitable operational temperature.
2. The backup air conditioning units consists of an outdoor unit and an indoor unit.
3. The indoor unit is rated 2400 BTU.
4. All the air conditioning units are part of the PKI Data centre construction project.
5. As per contract with Mantech (Ref:PKI Data centre Construction contract), all parts and fittings of the data centre are subject to two years warranty by Mantech from the date of the handover, which is 11 March 2007 (Ref: LTR/VP/07/08/CIO/H1)
6. All the air conditioning units have been tested prior to handover.
7. Emergencies:
a. In case of any malfunction of the air conditioning units, the Vendor shall be informed for any replacements (Ref: Doc 7.1B)

Ownership:

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Dust & Fire Protection OWI

Operating Work Instructions – Fire/Dust Detection & Fire Suppression System

Scope:

This document covers the Operating Work Instructions for the Fire/Dust Detection & Fire Suppression System located throughout the PKI Data centre in Isa Town.

Responsibilities:

The safe is the responsibility of CIO’s Administration Department.

Details of Operating Work Instructions:

1. CIO Isa Town’s Computer Room is protected by Fike Corporation’s SHP Pro Fire Protection System.
2. The system consists of :
a. Somke Fire/Dust Detectors (located on the ceiling void, roof and under the raised floorings)
b. Fike Corporation Single Hazard Panel(SHP) – Alarm/System Control Panel
c. FM 200 Gas tank and release nozzles
3. The Fire Protection System is installed by ALMoayyed Trading & Contracting.
4. This system is part of a project which includes the installation and commission of UPS, Main Air Conditioning Unit and Fire Protection System.
5. The Fire Protection System is regularly tested to by the Vendor.
6.
The SHP for the system is located on the outside of the Computer
7. Manual for the Fire Suppression System is available.
8. Emergencies:
a. When a fire is detected, the alarm siren will immediately sound, after 90 seconds the FM 200 gas will be released.
b. The release of the gas can be delayed by 1 minute by pressing a button on the SHP panel.
c. The SHP has a battery backup, in case of power failure.
d. For support, contact Al Moayyed Trading and Contraction 17700777.

Ownership:

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Access Control System OWI

Scope:

This document covers the Operating Work Instructions for the Access Control in PKI Data centre in Isa Town.

Responsibilities:

The access control is the responsibility of the Physical Security Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. Access to each of the room in the PKI Data centre is via Identix Fingerscan V20 UA biometrics fingerprint reader. The readers are connected to the fingerprint database pc in the Outer Core room via Ethernet.
2. Reader Description :
a. Identix Fingerscan V20 UA
b. Dimensions : Length: 6-1/2”, Width 6-3/4”
c. Enrollment time : <5 seconds
d. Verification time : <1 second
e. FAR/FRR: variable, configuration dependant
f. Template size: 512 bytes
g. Allowable Finger Rotation: =/1 18 degrees
h. Power: 12V DC, unregulated
i. Weight: 2lbs
j. Transaction Storage: 8000 (minimum buffering)
k. Communications: RS485, Wiegang, RS232;optional gateway-supported Ethernet or modem
l. Baud rate: 9600 to 57600 bps
m. Template storage: 512 or optional 5000 and 32000 template memory
n. Door controls: Lock output, tamper switch, 3 auxiliary outputs, 4 auxiliary inputs
o. Card reader input: Wiegand, proximity, magnetic stripe (serial), smartcard (serial), barcode(serial)
p. Card reader emulation output: Wiegand
q. Timezones: 30
r. Operating temperature: -10 to 50 degrees Celsius
s. Display: 2 line, 16 characters
t. Options: User memory expansions: 5000 and 32000 templates, LCD display, integrated proximity card reader, dial up modem, Ethernet communications (10BAST-t), and Fingerlan IV
3. Manual for the safe is available in the Manuals folder (Access control tab).
4. As part of PKI Data centre Construction project deliverables, the access control items has a 2 year warranty from the date of handover.
5. Security:
a. Entry would require a Physical security personnel and another person ie. all rooms require dual access.
b. A Physical Security personnel MUST be present in all room which requires access.
c. A user can use either his/her access code or an access card with his/her fingerprint to access.
6. Emergencies:
a. In case of power failure, access would not be available but the door lock will be powered.
b. In case of network failure between reader and Fingerlan pc, the reader would still be able to provide access with templates stored on the reader itself.
c. For support, contact Mantech 17730459.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue



Telephone OWI
Scope:

This document covers the Operating Work Instructions for the fully functional telephone located in the Outer Core room in PKI Data centre in Isa Town.

Responsibilities:

The fully functional telephone is the responsibility of the CIO’s Administration Department.

Details of Operating Work Instructions:

1. Telephone Description : Panasonic Phone KX-T2375JXW
2. The telephone is connected to a direct line in Isa Town. Phone number: 17878121. It is also connected to the intrusion alarm dialler which dials in case of emergency.(Refer to OWI – Alarm).
3. The telephone line is provided by Batelco, which provides exchange for the whole Isa Town building.
4. The wiring for the telephone line is done by Technoland.
5. Manual for the safe is available in the Manuals folder (Telephone).
6. Emergencies:
a. Should the telephone fails, the telephone line can be connected directly to the alarm.
b. If the telephone line is down, please contact Batelco on 17881111
c. If the telephone line is down due to error in wiring, contact Techoland on 17271714.

Ownership:

This document is owned by CIO’s Administration Department.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Safe OWI

Scope:

This document covers the Operating Work Instructions for the Safe located in the Safe room in PKI Data centre in Isa Town.

Responsibilities:

The safe is the responsibility of the PKI Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. Safe is a Media rated TL-15 safe
2. Safe Description : Chubb Safe Europa Grade 1 Size 2
3. Front safe door is protected by digital combination lock and a key. The deposit boxes in the safe have dual locks. One individual key and one common key for all locks.
4. Manual for the safe is available in the Manuals folder (Safe tab).
5. As part of the PKI Data centre construction project, the Safe has a 2 year warranty and support from Mantech from the date of delivery.
6. Security:
a. The digital combination for the safe door and the safe door key will be held by different individuals. If needed, the combination lock can also be set to require 2 user inputs instead of it. Current setting is set to 1.
b. One personnel will hold the common key to all deposit boxes while and individual responsible for the safe deposit box will hold the individual key.
7. Emergencies:
a. In case of fire, the safe is rated to withstand fires up to 2 hours
b. If the batteries to the combination lock have not been changed in time and the tension does not suffice to cancel the lock’s blocking feature, a new 9V ALKALINE battery can be pressed to the contacts on the entry pad.
c. The code the safe remains active even as the power supply fails.
d. For support, contact Mantech 17730459.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

Door Exit Push Buttons & Door Latch OWI
Scope:

This document covers the Operating Work Instructions for the Door Exit Switches and Door Latches in the PKI Data centre

Responsibilities:

The items are the responsibility of the PKI Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. There are 4 door exit push buttons and 4 door latches in the PKI Data centre
2. Exit Push Button Description : ALPRO Waterproof Exit Switches with Solid State Piezo technology with PUSH TO EXIT engraving
3. Door Latch Description : Trimec TS2001 Stainless Steel Mortice Latch Release (Monitored)
4. Pushing of the exit button releases the door latch, allowing exit. Both the exit button and the door latch are connected to the Access Control Biometrics (Refer to OWI – Access control).
5. Both latch and exit buttons are part of PKI CA Data centre construction project which has a two year warranty from the date of handover (Ref: PKI CA Data centre contract).
6. Emergencies:
a. The door latch is held magnetically via power from the Data centre. In case of power failure, the battery in the Access control is to provide power to the latch until power supply is restored.
b. In case of any failures, contact Mantech 17730459.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

CCTV OWI

Scope:

This document covers the Operating Work Instructions for the CCTV Cameras, DVR Remote Control ,Monitor, Digital Video Recorder (DVR) and coaxial cables located in the Outer Core room in PKI Data centre in Isa Town.

Responsibilities:

The safe is the responsibility of the Physical Security Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. Three CCTV cameras are connected via coaxial cables to the DVR. The monitor is attached to the DVR and DVR can be controlled using keypads on the DVR or via remote control.
2. Descriptions:
a. CCTC Camera – Infinova V1466F-3895A14 CCTV, Vandal resistant x 3
b. DVR - Infinova V3010/4L Digital Video Recorder,4 Channels 80 GB Hard disk
c. Monitor - Infinova V1322T/14 14” Digital Color Monitor 1 channel
d. Coaxial cables - LOT

3. The CCTV camera monitors:
a. Entrance to the Outer Core room
b. Entrance to the Inner Core room
c. Entrance to the Safe Room.
4. The DVR is set to capture only movement detected by the CCTV cameras.
5. The CCTV cameras is also able to capture movement in 0 LUX(no lights) as such the lights to the data centre are switched off when not occupied.
6. The manual for all the items mentioned above is available in the Manuals folder.
7. Security:
a. Access to the DVR is protected via a PIN code. PIN code can be entered using keypad on the DVR or via the remote.
b. The DVR is also accessible via Infinova’s Remote Monitoring Software.
c. Setup of the DVR can be done either via the DVR or by using the Remote Monitoring Software.
8. Footage from the DVR will be periodically downloaded to the PC with the Remote Monitoring Software installed.
9. As part of PKI Data centre Construction project deliverables, all the items above have a 2 year warranty from the date of handover of project.
10. Emergencies:
a. In case of lost feed from cameras, please contact Mantech 17730459 for support.

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue


Light Fittings & Switches OWI

Scope:

This document covers the Operating Work Instructions for the Lights fitting and switches located throughout the PKI Data centre in Isa Town.

Responsibilities:

The lights fitting and switches is the responsibility of the PKI Section of CIO’s Information Security Section.

Details of Operating Work Instructions:

1. All the lights fitting and switches are part of the PKI Data centre construction project.
2. As per contract with Mantech (Ref:PKI Data centre Construction contract), all parts and fittings of the data centre are subject to two years warranty by Mantech from the date of the handover, which is 11 March 2007 (Ref: LTR/VP/07/08/CIO/H1)
3. All the lights fittings and switches have been tested prior to handover.
4. Emergencies:
a. In case of any breakage/malfunction of the lights fittings and switches, the Vendor shall be informed for any replacements (Ref: Doc 7.1B)

Adlin Hisyamuddin
Information Security Manager

____________________________

On:

08 November, 2007
____________________________

Change history

Issue 1 08 November, 2007 Initial issue

17. Appendix IV

Appendix IV – Place Organizational Chart here

17. Appendix V – Standards & Compliance

PDF [29] All future assets used in the Trust Centre must conform to the following, as applicable:



Owner


Organization


Function


Address


Contact


Telephone


E-mail


Web

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PKCS Standards : RSA Token : Digi-Sign.com

PDF [1]
7.10 PKCS#11
7.11 PKCS#12
7.12 PKCS#15

PKCS#11

PDF [1] Digi-CA uses a PKCS#11 API standard to perform Cryptographic functions using either HSM devices or using its own Cryptoki application based layer.

PKCS#12

PDF [1] Digi-CA™ fully supports the PKCS#12 standard and implements it for key and certificate distribution.

PKCS#15

PDF [1] This standard has been formed to define smart card standards [10] for key & certificate storage and Digi-CA™ [2] complies with this standard, as the Digi-Card™ smart cards provided for use with the Digi-CA™ are compliant with this standard because they have been designed by the vendors in accordance with the PKCS#15 standard.

SAS 70 Key Ceremony

Introducing the SAS 70 Key Ceremony

PDF [52] For compliance reasons, certain CA systems must conduct a Key Ceremony before issuing any Digital Certificates. Trust Centres and Government projects are two examples where a key ceremony may be required in order to comply with local laws or international standards.

The entire Key Ceremony and is described in this manual. There are typically three phases of the Key Generation Ceremony and these are sub divided and described in the following sub sections:

Digi-CA™

PDF [53] The Root CA, that is at the top of the hierarchy of the CA environment, as well as Subordinate CAs residing on a lower level of the CA hierarchy, are created using the Key Ceremony. The Key Ceremony is conducted and supervised by the Key Ceremony Administrator with an optional support of Key Generation Ceremony Administrator and the procedure is carried out with the following primary responsibilities:

  • Generating Cryptographic Key Pairs
  • Creating properly named and configured CAs.
  • Creating CAs in a secure, auditable manner that can be trusted.
  • Providing ongoing CA support and maintenance.



To meet these responsibilities, the Key Ceremony Administrator is involved in every phase of the CA life cycle. The six phases of the CA life cycle are described in the following sub sections:

        1.Key Generation Ceremony

        2.Definition

        3.Preparation

        4.Creation

        5.Activation

        6.Maintenance

        7.Recertification

  • Key Generation Ceremony
  • During a Key Ceremony in which a CA is created, usually either new cryptographic key pair is generated and assigned to a new CA or alternatively a previously generated (pre-generated) key pair can be assigned to a new CA. Cryptographic key pairs are generated during a key generation ceremony, that itself can either be a separate event (i.e. previously performed Key Generation Ceremony or a Key Ceremony related to recertification of an existing CA) or a part of the entire Key Ceremony and the latter is described in this manual. There are typically three phases of the Key Generation Ceremony and these are described in the following sub sections:

          1.Key Access Component Card Set Configuration
          2.Key Pair Generation


Key Access

Key Access Component Card Set Configuration

PDF [53] During this phase of the Key Generation Ceremony, a new Key Access Component Card Set, commonly referred to as Operator Card Set, can be created and bound to a cryptographic device’s security infrastructure.

Depending on the organization preference and/or regulatory requirements, all of the generated keys (or alternatively only a specified subset of generated keys, subject to the type of CA that they will be assigned too) may require protection from unauthorized access and may also require encryption using an encryption key that is divided into a specified number of components. These are referred too as Secret Components and once created they are stored on Key Access Component Cards.

If you choose to protect any keys with a set of Key Access Component Cards, you will need to create the new Key Access Component Card Set using the features provided by your cryptographic device vendor (e.g. HSM or other device). This will usually require you to define the card set configuration, such as the total number of cards in a card set and a minimum number of cards required to access the key (if you enable this option), to recover any lost card of the card set (if you enable this option), to recover lost PIN codes, that protect access to each card (if you enable this option) and finally - to recover a private key itself (if you enable this option).

Before a card set can be created, a sufficient number of Card Holders, that is individual persons holding the Key Access Component Holder responsibilities, should be appointed and attend the ceremony. Choose your Card Holders carefully and wisely and ensure they meet Trusted Employee requirements and other personnel related policies within you or your customer’s organization.

Each Card Holder, will need to be supplied with a special smart card, provided by the cryptographic device vendor. During the process of creation of a new Key Access Component Card Set, each Card Holder will be requested to insert the card into the smart card reader interface connected directly to the cryptographic device and enter and confirm a new PIN code they wish to protect their cards with. They must memorize their PIN codes and also store these securely in a well protected place such as safe. Before the process is completed, the Key Ceremony Administrator will also need to enter a Name for the newly generated card set in order to be able to identify it when the particular card set is needed in future use.

Upon successful creation of the new Key Access Component Card Set, the event should be documented in the Key Ceremony Notes Document, that should clearly display the Name assigned to the new Key Access Component Card Set, full name of each Card Holder, their personal details allowing the company, for which the keys are generated for, to easily contact each Card Holder when needed, and finally - the serial numbers of the smart cards they hold. The Key Ceremony Administrator should also ensure, that each Card Holder signs a dedicated Key Access Component Holder Document (a separate document for each Card Holder), which lists all of the Cart Holder responsibilities, their personal details and the Serial Number of the Key Access Component Card they hold.

Key Generation

Key Pair Generation

PDF [53] During this phase of the Key Generation Ceremony, the necessary number of key pairs is generated, subject to the number of CAs that will be created during the Key Ceremony. All private keys are securely generated and saved in an encrypted format on a cryptographic device, most often a hardware device such as Hardware Cryptographic Module commonly referred to as HSM. Public key request files are also saved into a hard disk drive, CD disc, USB flash drive or a diskette.

At this stage, the key pairs are given a Common Name and as an option, a unique key identifier file is named and saved into a hard disk, USB flash drive or a diskette. These values identify the key and will allow the Key Ceremony Administrator to properly setup the cryptographic tools to access the key at a later stage of the Key Ceremony and in future frequent use if necessary.

In order to generate a key pair on a cryptographic device, a command prompt based
cryptographic device support software in combination with Digi-CA™ Cryptographic Toolkit can be used. Subject to your or your customer preference, or regulatory requirements as well as supported algorithms by the Digi-CA™ PKI System and the cryptographic device in use, the Key Generation Administrator needs to ensure, that he has correctly defined the following values describing the type and the size of each private and public key pair:

          a. Key Generation Algorithm [i.e. RSA]

          b. Key Size provided as an integer number of bits [i.e. 2048]



Ensure, that these values are known to the Key Generation Administrator in advance and that your own or your customer’s company understands their meaning, usage limitations and security risks in respect to the current cryptographic security norms and standards [10] for commercial use.

If you intend to protect a particular key with a set of Key Access Component Cards, ensure all Key Access Component Holders are present at the ceremony, have their cards ready for use and confirm that they remember or have access to the PIN codes necessary to read data on the cards. If an Key Access Component Card Set key protection feature is enabled during this phase, configured number of Card Holders will be requested to insert the card into the smart card reader interface connected directly to the cryptographic device and enter the PIN code they used to protect their cards with. Once the last required card is loaded, the cryptographic device will automatically generate the requested key data based on the specified key type algorithm and bit size and output relevant data such as certificate request containing the associated public key and as an option, a unique key identifier file to an appointed location on a hard drive disk, CD disc, USB Flash Drive or a diskette.

At the end of the key generation process, you need to ensure, that the event is documented in the Key Ceremony Notes Document and, that it clearly displays that keys are not only correctly associated with a specific company, for which the key or keys are generated for but also correctly associated with the CA, for which these were generated for. For example, ACME Certification Authority could be assigned to 2048 bit RSA PrivateKey1, etc.

After the Key Ceremony, the CA Operator uses the .x509 certificate file, generated during the ceremony, to map the private key stored on the cryptographic device to the new CA infrastructure.

The above process for generating keys can be completed using a cryptographic device working in a production environment and it does not disrupt the operations of other CAs maintained in your Digi-CA™ PKI System environment. This also enables the CA Operator to bring new CAs online easily, without taking existing CAs offline.

Using Key Generation Ceremony, a new key pair is generated whenever a new Root or Subordinate CA is created. Typically, firstly a Root CA is created and used to sign any new Level 1 Subordinate CA in the CA hierarchy and so on.

Definition

PDF [53] During the definition phase of the CA, the Key Ceremony Administrator coordinates and supervises work to define the CA, how to name it, how to use it, what type of hierarchy to choose, and other attributes and requirements of the CA and associated PKI [30] environment. This can be done by using the Preset Certificate Specification Template provided in Appendix II.

There are several other items that must be considered when defining the Key Ceremony and these are explained in the following sub sections:

            1. Naming Document

2. Key Map

3. Key Access Component Holders

4. Key Ceremony Script

5. Video Recording

6. Archive Collateral


Naming Document

PDF [53] The naming document must be completed for all new CAs. Information provided in the naming document precisely describes the CA you are creating for your own organization or for your customer. Because this document is a critical tool in the creation of the CA, it is imperative that the parameters identified in the naming document are carefully defined. The Digi-Sign’s Digi-CAST2™ Consulting Team can support the Key Ceremony Administrator and work with the customer to correctly set these parameters.

Important Note: The Key Ceremony Administrator is responsible for generating the Naming Document and ensuring that its is signed by appropriate representatives or by the customer, to whom the CA is generated for.

The naming document is a critical tool used to prepare for a Key Ceremony. With the naming document in hand, the ceremony is scheduled, the Key Ceremony Script is written and the ceremony attendees are decided upon. The naming document consists of four sections and space for the customer signature (see Appendix II: Preset Certificate Specification template). The information in each section differs, depending on the CA type and unique customer specifications. The typical two types of CAs you create in key ceremonies are:

  • Root CA, which is the top level CA of the new CA hierarchy and signs lower level CAs within the hierarchy.
  • Subordinate CA, which is part of the CA hierarchy with Root CA residing on top of it.



Elements of the naming document are different for each of these CAs. These differences are summarized in the following table:

IMAGE


Naming Document Sections

Four sections of the Naming Document

PDF [53] The four sections of the Naming Document are explained in the following sub sections:

            Section I- New Issuing Authority Organization

Section II- Operational Period

Section III - Distinguished Name

Section IV - Certificate Format & Extensions


  • Section I – New Issuing Authority Organization
  • This section lists the name, address and country of operation of the New Issuing Authority and is the organization that the CA will be generated for.

  • Section II – Operational Period
  • This section identifies the validity period showing the integer value representing the number of years, for which the particular CA is going to operational. The value is subsequently used to calculate the CA expiration date subject to the real date and time value of CA generation event, provided as UTC.

  • Section III – Distinguished Name
  • This section specifies the Distinguished Name [DN] of the New Issuing Authority (new CA) and the Superior Issuing Authority (higher level CA, commonly referred to as the signer and the issuer), that is issuing the new CA, if applicable. There are two sections to the DN section of this element of the Naming Document and these are described in the following sub sections:

          Name of Superior Issuing Authority

          Name of New Issuing Authority


    • Name of Superior Issuing Authority
    • This section lists the Distinguished Name of the Superior Issuing Authority. The Superior Issuing Authority is the CA, that signs the new CA certificate. The Superior Issuing Authority is also referred to as the issuer and the signer. The Superior Issuing Authorities for the types of CAs you may want to generate are as follows:

      • For a new Root CA, where there is really no Superior Issuing Authority and the Root CA certificate is self-signed, the Superior Issuing Authority Distinguished Name must exactly match the New Issuing Authority Distinguished Name.
      • For a new Subordinate CA, where the Superior Issuing Authority is either a Root CA or another Subordinate CA of a higher level, the Superior Issuing Authority Distinguished Name must match the Distinguished Name of:
      • a. for Level 1 Subordinate CAs, the Root CA

        b. for Level N Subordinate CA, lower than Level 1, a Subordinate CA of a Level higher
        than N (levels are to be interpreted in a reversed counting order)

      In each of the above instances, the value of the Superior Issuing Authority Distinguished Name must always match the value of the Distinguished Name of the CA that actually signs the new Subordinate CA certificate.


      The Distinguished Name of the Superior Issuing Authority is defined using the following attributes:

              • CA Email Address (E) – as an option
              • Organizational Name (O)
              • Organizational Unit Name (OU)
              • Common Name (CN)
              • Locality (L) – as an option
              • State or Province (S) – as an option
              • Country Name (C)

      Important Note: The country name attribute should be chosen from a list of registered country names, with associated country codes, as defined by the ISO 3166 standard.

Name of New Issuing Authority

PDF [53] The second part of this section lists the Distinguished Name of the New Issuing Authority. The New Issuing Authority is the new CA that you create. There are several common attributes that may be required or optional subject to your preferred choice and regulatory requirements:

    • The Email Address (E) attribute is optional and may represent a valid RFC822 email address, which can be used by certificate subscribers, associated parties, other third parties and legal bodies for S/MIME based communication with the organisation maintaining the CA infrastructure.

    • The Organizational Name (O) attribute must be an Organizational Name. This attribute is your own or your customer’s full and complete company name as registered within applicable national authorities.

    • The Organizational Unit (OU) attribute must be an Organizational Unit Name, to which the CA maintenance has been assigned to.

    • A second OU attribute may be defined and can refer to a Repository Location, where usually all legal documentation, such as Certificate Practice Statement [26] and CP are stored, and is available to the public community.

    • The Common Name (CN) attribute is the nickname for your or your customer’s new CA. For example, it could be ACME Individual Subscriber CA.

    • The Locality Name (L) attribute is optional and represents the City or Town, where your own or your customer’s company is located in. The value of this attribute – if provided – must match the information provided to the appropriate national authorities at the time of the company registration.

    • The State or Province attribute (S) is also optional and represents the State or Province or other name of a recognized area, where your or your customer’s company is located in. The value of this attribute – if provided – must match the information provided to the appropriate national authorities at the time of the company registration.

    • The country name (C) attribute should be chosen from a list of registered country names, with associated country codes, as defined by the ISO 3166 standard and should represent the country in which your or your customer’s company is registered and operates in.


  • Section IV – Certificate Format & Extensions
  • This section specifies the extensions included in the certificate, that define how it is used and also points to the correct CPS that the new Certificate complies with.

    Important Note: The CPS for the CA must include a description of how the CAs are created and formatted.

Key Map

PDF [53] To track the assignment of pre-generated Keys, a Key Map is maintained and updated before and after every Key Ceremony you conduct (see Appendix III for a sample Key Map template). This file contains the following information that is explained in the sub sections below:

            1 Issue Date

            2 Private Key and Cryptographic Device

            3 Subject DN

            4 Issuer DN

            5 .req File

            6 x509 File

            7 Validity Period


1 Issue Date

This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the date of the Key Ceremony and precise UTC time of assignment is entered in this field.


2 Private Key and Cryptographic Device

This field identifies the cryptographic device and the pre-generated (or generated at the beginning of this ceremony) private key residing within your cryptographic device. The device is usually identified by a unique device serial number that the device vendor has assigned to it. If provided by the vendor of your device, you may also enter the integrity key identifier value, that provides an increased level of device identity assurance. As next items in this section, you enter the Common Name and optionally a unique key identifier file name and the checksum byte string of the identifier file for your pre-generated key stored within the cryptographic device. As a last item in this section and if the additional Key Access Component Card based protection was enabled for the generated key, you enter the Name of the Key Access Component Card Set, which was used to protect access to the key. When the key pair is assigned to a new CA, these values will be cross-checked by the appointed Key Ceremony Attendees, to ensure they match the real values, that the Key Ceremony Administrator is using during the ceremony key related activities.


3 Subject DN

This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the Distinguished Name [DN] of the new CA is entered in this field of the spreadsheet.


4 Issuer DN

This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the DN of the Issuing CA is entered in this field of the spreadsheet.


5 req File

This is the name of the file containing the public key and the certification [10] request generated during the Key Ceremony. The request file assigns the CA to a pre-generated key.


6 .x509 File

This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a certificate for the new CA is created and once this is done the name of the certificate file is entered in this field of the spreadsheet.


7 Validity Period

This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a validity period will be assigned to the new CA and is entered here once completed.

Key Map

PDF [53] To track the assignment of pre-generated Keys, a Key Map is maintained and updated before and after every Key Ceremony you conduct (see Appendix III for a sample Key Map template). This file contains the following information that is explained in the sub sections below:

            3.11.2.2.1 Issue Date

            3.11.2.2.2 Private Key and Cryptographic Device

            3.11.2.2.3 Subject DN

            3.11.2.2.4 Issuer DN

            3.11.2.2.5 .req File

            3.11.2.2.6. x509 File

            3.11.2.2.7 Validity Period


3.11.2.2.1 Issue Date

This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the date of the Key Ceremony and precise UTC time of assignment is entered in this field.


3.11.2.2.2 Private Key and Cryptographic Device

This field identifies the cryptographic device and the pre-generated (or generated at the beginning of this ceremony) private key residing within your cryptographic device. The device is usually identified by a unique device serial number that the device vendor has assigned to it. If provided by the vendor of your device, you may also enter the integrity key identifier value, that provides an increased level of device identity assurance. As next items in this section, you enter the Common Name and optionally a unique key identifier file name and the checksum byte string of the identifier file for your pre-generated key stored within the cryptographic device. As a last item in this section and if the additional Key Access Component Card based protection was enabled for the generated key, you enter the Name of the Key Access Component Card Set, which was used to protect access to the key. When the key pair is assigned to a new CA, these values will be cross-checked by the appointed Key Ceremony Attendees, to ensure they match the real values, that the Key Ceremony Administrator is using during the ceremony key related activities.


3.11.2.2.3 Subject DN

This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the Distinguished Name [DN] of the new CA is entered in this field of the spreadsheet.


3.11.2.2.4 Issuer DN

This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the DN of the Issuing CA is entered in this field of the spreadsheet.


3.11.2.2.5. req File

This is the name of the file containing the public key and the certification [10] request generated during the Key Ceremony. The request file assigns the CA to a pre-generated key.


3.11.2.2.6 .x509 File

This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a certificate for the new CA is created and once this is done the name of the certificate file is entered in this field of the spreadsheet.


3.11.2.2.7 Validity Period

This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a validity period will be assigned to the new CA and is entered here once completed.

Key Access Component Holders

PDF [53] A CA’s private key is a valuable item because its possessor may activate the CA at any time. To protect against any misuse, Key Access Component Card Sets are created and are required to access the private key.

These Card Sets are formed with a defined number of Key Access Component Cards, that are protected with PIN numbers and store encryption key elements [components] necessary to decrypt the private key and gain access to it in order to bring it into online state inside the cryptographic device. Individuals, that posses the Key Access Component Cards used to protect particular keys are called Key Access Component Holders and the organization that owns the CA must track and record accurate information about Key Access Component Cards and Key Access Component Holders so that a complete list maintained at all times.

  • Key Ceremony Script
  • It is essential, that the Key Ceremony produces an unbroken evidentially path demonstrating that every aspect of the certificate generation process occurred in accordance with methods and procedures that comply with regulatory requirements and relevant standards [10]. A sample Key Ceremony Script is available in Appendix IV but be careful to note that this is a sample only and a unique Script should be written for the specific environment, Certificate Practice Statement [26] and CP.

    Sufficient evidentially material must be generated to demonstrate, should such a demonstration be required by law, that proper practices were followed during the ceremony. For this reason, every Key Ceremony is conducted from a written script. To achieve a high degree of confidence, each ceremony step must be witnessed, documented, and certified.

    The specific benefits of using scripts to perform the ceremony include:

    • An increased likelihood that potential errors are identified during a dry run, rather than during the ceremony.
    • The ability to use scripts as reference documents in planning future ceremonies.
    • The support that scripts provide that engenders the trust by end users.
    • The audit trail that scripts provide.

    Important Note: Conduct a practice run any time a new step is introduced and practice this before the actual Key Ceremony. The dry run provides confidence that everything will work on the day of the ceremony. During the practice run, use the naming document and script that have been prepared for the actual Key Ceremony. It is recommended to use test smart cards and hardware that will not be used during the actual Key Ceremony.

  • Video Recording
  • For auditing purposes, Key Ceremonies are recorded by video and sound. The video recording should continuously capture the Operator Cards, Key Access Holders and the ceremony proceedings. Therefore the personnel must be seated to the left or right of the hardware used during the ceremony. All actions and personnel should be visible at all times.

    Once completed, the video recording should be stored with the other Archive Collateral in the Archive Folder.

Archive Collateral

PDF [53] The Key Ceremony Administrator ensures that every Key Ceremony and every ceremony related activity is secure and auditable. This means that there must be an unbroken evidentially path demonstrating that your Certificate system is operated in accordance with the methods and procedures described in your organization’s Certificate Practice Statement [26]. In addition to the witnessed script, video record of key ceremonies and logging protocols provide further documentation of the CA creation process. Each of these is explained in the following sub sections:

Archive Folder

An Archive Folder must be compiled for every Key Ceremony. The folder should include the Naming Document, the witnessed Key Ceremony Script, the Key Access Component Holder Documents, the Attestation Letters and the Key Map. After the ceremony, the Archive Folder is stored in the secure storage area. This Folder and the video recording provide the primary record of all key ceremonies performed by the organization.

The Archive Folder documents the Key Ceremony and provides evidence of the secure manner in which the CA was created. The Archive Folder is divided into three parts as described in the following sub sections:

            1.Naming Document

            2.Key Map

            3.Key Access Component Holder Documents

            4.Attestation Letter


  • Naming Document
  • The Naming document(s) is associated with the CA(s) that were generated using the Key Ceremony Script that was initialed by the witnesses. The Naming Document and Key Ceremony Script are described earlier in this section.

  • Key Map
  • The Key Map document is associated with the CA(s) that were generated using the Key Ceremony Script that was initialed by the witnesses. The Key Map and Key Ceremony Script are described earlier in this section.

  • Key Access Component Holder Documents
  • There is one Key Access Holder Component Document used for each Key Access Component Holder (a dedicated Card Holder within a defined Key Access Component Card Set, that protects access to the private key stored on a cryptographic device), that provides photographic identification of each Key Access Component Holder. The document also contains the date, the name of the CA, the Card Set Name, Card Serial Number, Private Key Common Name and the Key Access Component Holder’s responsibilities as they relate to card he holds. During the distribution event, at the end of the Key Ceremony, all the Key Access Component Holders sign each page of their respective Key Access Component Holder Document to indicate they understand their responsibilities. The document is dated and is initialed by the Key Ceremony Administrator and cross signed by the Notary, or equivalent public official. A sample Key Access Component Holder Document can be seen in Appendix V.

  • Attestation Letter
  • Every step of the Key Ceremony Script is verified by the witnesses and each page of the Script is initialed as it is completed during the ceremony. At the end of the Key Ceremony, the witnesses then sign the Attestation Letter to provide further documentation that the published procedures were followed. The Attestation Letter is dated and initialed by the Key Ceremony Administrator and cross signed by the Notary, or equivalent public official to certify the signatures on the Letter. See the sample Attestation Letter is in Appendix VI.

Preparation

PDF [53] Once everything is defined and understood the preparation for the Key Ceremony can be considered. This involves preparing the people that will attend, the keys that will be generated and the documentation that is required. These are explained in the following sub sections:

            3.11.2.1 Key Ceremony Attendees

            3.11.2.2 Notary Public or Equivalent


    • Key Ceremony Attendees
    • In preparing for the Key Ceremony, personnel from your Customer’s organization must attend. It is essential to remember at all times that Digi-CA™ is a security product. Throughout the entire Key Ceremony and beyond, every action must occur in a manner that conveys that care has been taken to ensure the highest possible level of security.

    • Notary Public or Equivalent
    • A notary public is an official, public witness whose job it is to identify people who are about to sign a document and to witness that signing. A properly credentialed notary public or some person who is authorized by local law to serve as an official, public witness, observes the witness(es) signing the Attestation Letter and then certifies the witnesses’ signatures.



Creation

Once everything necessary to define and prepare for the new CA is completed, the CA is created in a Key Ceremony. This is a set of formal and highly secure procedures that creates a CA. The Root CA should be stored securely and remain in offline state, while Subordinate CAs can be put online for frequent use. There are a number of actions, that should occur on the day of the Key Ceremony and they are explained in the following sub sections:

            1.Key Access Component Retrieval

            2.Pre-Check

            3.Briefing

            4.Ceremony

            5.CA Creation

            6.Conclusion

            7.Post-Check


Access Component

Key Access Component Retrieval

PDF [53] Key Access Component Retrieval is only required if you are using existing Key Access Components from a previous Key Ceremony and this is decided when the Ceremony Script is being written. Existing Key Access Components are needed each time a CA is being created from a previously generated key, if the key was access protected. The Key Access Component Holders must then be present so that the Key Ceremony Administrator and the Key Access Component Holders can enter the safe room together and retrieve the required smart cards containing Key Access Components (key elements necessary to decrypt the private key and bring it online). The Key Access Component Holders will provide their smart cards as required during the Key Ceremony.


Pre-Check

A final check of the Key Ceremony room should be undertaken prior to the arrival of the attending personnel. This could include assisting with the recording equipment, arranging seating and other activities but should always include a check, that the following items are present, will function properly and are usable:

          • Archive Book
          • Key Ceremony Administrator script
          • Key Ceremony Witness script
          • Key Access Components
          • Workstation or a Server
          • Entry/Exit Log (see Appendix VII)



Briefing

Before the ceremony, the Key Ceremony Administrator, or a Digi-Sign Digi-CAST2™ consultant, meets with the attendees and explains what a Key Ceremony is and what will be occurring during the ceremony. The briefing will include:

          • The steps and processes used in creating a CA.
          • The security requirements for the CA (and why they are important).
          • Answer any questions from the participants.



Ceremony

The actual Key Ceremony has several vital components that must be understood by everyone that attends the ceremony. There are four parts to the ceremony and the following sub sections explain the components:

            1.Key Ceremony Introduction
            2.Key Ceremony Script Adherence
            3.Key Ceremony Events
            4.Key Ceremony Conclusion


Introduction

Key Ceremony Introduction

PDF [53] On the day of the ceremony, many people become involved in making the ceremony a success. The following identifies the tasks performed on the ceremony day, the time frame, the responsible party, and other participants involved in each task. The following table shows the responsibilities on the day of the Key Ceremony:

Time Frame Task Responsible Party Other Participants
30 minutes-1 hour before ceremony begins Key Access Component retrieval, Video camera setup Key Ceremony Administrator Key Access Component Holders, access personnel, Videographers
15 minutes before ceremony Final check of the ceremony room Key Ceremony Administrator
15 minutes before ceremony Customer briefing Digi-CAST2™ Consultant or Key Ceremony Administrator Customer
Start of ceremony Ceremony introduction Key Ceremony Administrator Key Ceremony Administrator, Key Access Component Holders, and other ceremony participants
During ceremony Create the customer’s CA(s) Key Ceremony Administrator Key Access Component Holders, witnesses, and customer (optional)
End of ceremony Ensure that all ceremony material is properly distributed Key Ceremony Administrator Key Access Component Holders and access personnel
Immediately after ceremony ends Ensure that the archive book and appropriate key management files are updated and stored Key Ceremony Administrator Access personnel Notary Public

After entering the room, follow these steps:

  • Place the archive book on the Inventory table.
  • Put the script on the table next to the workstation that will be used.
  • Lay out all the storage media so it is visible to the fixed camera.
  • Ensure that the Entry/exit Log Book is accessible to everyone.

Upon successful completion of the final check, the ceremony room is ready for the ceremony participants. Next, make sure all the participants are present and in their proper location. The participants should be arranged as follows:

  • Position the videographer(s) behind the cameras.
  • Seat witnesses next to the workstation where they can verify each step performed.
  • Position the notary public or equivalent official and any other ceremony observers where they do not obstruct the view of the Key Access Holders and witnesses.
  • In preparing to start the ceremony, remember that you represent an organization in which your users must place a high degree of trust. To confirm that their trust in your organization is well placed, your every action must convey the preparation and care taken to ensure the highest possible level of security.

    The introduction part of the Key Ceremony is not a scripted event. It is the responsibility of the Key Ceremony Administrator or Digi-Sign Digi-CAST2™ Consultant, to ensure that everyone in attendance understands what is happening at each stage of the ceremony.

    At the onset of the ceremony, the Key Ceremony Administrator introduces the participants and sets the stage for the ceremony, covering the following points:

  • Point out main features of the ceremony room. Explain that the ceremony facility is equipped with the workstations and other equipment that will be used in the Key Ceremony. And that the hardware includes smart cards, the HSM and the server with the Digi-CA™ installed.
  • The Key Ceremony Administrator explains, that various commands and actions will be executed to perform the functions required for the ceremony. Remind the participants, that a function of the ceremony is to produce sufficient evidentiary materials to demonstrate, that proper practices are followed throughout the ceremony. Therefore, each ceremony step is witnessed, documented, and attested to.
  • To provide additional documentation, ceremonies are videotaped and the Key Ceremony Administrator should explain, that the video(s) will always focuses on the Key Access Holders, smart cards and the other ceremony proceedings. Remind everyone, that the videotape records proprietary processes and copies of the recordings are not provided to anyone.


Script Adherence

PDF [53] The Key Ceremony is a formal procedure in which the CA is created. The security of the procedure must be auditable and evidentially. The ceremony script is the most important tool to ensure compliance [10] with established security procedures. When each ceremony step is documented, witnessed and attested to, you have created your organization’s strongest proof against claims of non-compliance or security compromise. For this reason, the script must be followed exactly as it is written.

During the Key Ceremony, the script will be read aloud for each step. Reading the script aloud helps the ceremony participants follow along, but more importantly, it provides a verbal narrative to accompany the video recording of the event. As each step is completed, the section of the script for that step is initialed by the witnesses.

Important Note: Situations that cause temporarily digression from the script may arise. Any such digression must be thoroughly documented, so that these situations do not compromise the security of the process.

To properly document digressions, notations are made in the script that describe the problem, when it occurred, and what was done to fix the problem. The script is initialed by everyone in attendance.

If the ceremony is particularly long, the participants can take a break from the proceedings. If this occurs, the script has a notation added indicating the time of the break. Another notation indicating the time the proceedings resumed is also made in the script. During the entire break, two trusted employees must remain in the room. The videographers continue recording throughout the break.


Key Ceremony Events

Following the ceremony introduction, the scripted steps to create the CA begin. The script is followed exactly so that the witnesses can initial each and every step as it is performed. The following sub sections describe the ceremony activities that will be in the script:

            1.Initializing Event

            2.Generating Event

            3.Signing Event

            4.Distribution Event


Initialising Event

PDF [53] The initializing event must be built into the script when creating a Root CA or when conducting a Key Generation Ceremony. In the Initializing Event, the Key Access Component Card Set is created (Key Access Component Cards). The Initializing Event provides critical security to protect the private key assigned to the new CA. This event is of paramount importance during the ceremony, and these procedures must be adequately documented in the script.

  • Generating Event
  • When generating request files or keys, the Key Ceremony Administrator must build a generating event into every script prepared. In the generating event, the Cryptographic Operation Control Software (Cryptographic Device Support software and Digi-CA™ PKI [30] Toolkit) generates a request file. At this stage, the Key Access Component Holders provide their smart cards and these are used to activate the offline (previously generated) private and public key pair, that will be assigned to the new CA.

    The Key Access Component Cards allow the activation of the private key within the cryptographic device and enable the device to generate the request file. The request file assigns that key pair to the certificate of the new CA. The Key Map file identifies the Common Name of the pre-generated key, which is to be associated with the new CA.

    The Common Name of the pre-generated key also identifies the CA type. This information enables the Cryptographic Operation Control Software to generate an accurate request file with support of the cryptographic device.

  • Signing Event
  • There must be a signing event in every prepared script, except for Key Generation Ceremony scripts. In the signing event, the Key Access Component Cards are used to activate the signer (the superior issuing authority). The signer is determined by the PKI hierarchy into which the new CA fits:

    • Certificates for Root CAs are self-signed

    • Certificates for Subordinate CAs are signed by the the Root CA or a Subordinate CA of a higher level within the CA hierarchy.

    These Key Access Component Cards enable the signer to sign the certificate of the CA being created. The script should identify the new Distinguished Name, the validity dates, and the extension settings that are provided in the Naming Document. During the ceremony, this information is entered before directing the Cryptographic Operation Control Software to sign the Certificate.

  • Distribution Event
  • The Key Ceremony script must also document the following steps in the distribution event:

    • 1.Distribute the newly created Key Access Component Cards to the Key Access Component Holders.
    • 2.Witnesses sign Attestation Letters indicating that they read the script, observed the ceremony and attest, that the ceremony was performed as described in the script.
    • 3.Key Access Component Holders sign the Key Access Component Holder Document indicating, that they have read, understand and agree to follow the duties and responsibilities of a Key Access Component Holder and that they have witnessed the signature of all the other Key Access Component Holders.
    • 4.Direct the notary or equivalent official, public witness to notarize (certify signatures on) the witnesses’ Attestation Letters.

Key Ceremony Conclusion

PDF [53] The Key Ceremony script then lists the steps that will be performed at the conclusion of the ceremony. Before anyone leaves the room all copies of the signed Key Ceremony Script, the Key Access Component Holder Documents, the Attestation Letters and the Video Recordings must be placed in the Archive Folder and sealed.

At this point, the CA is created but it is not yet activated. This is the next event that occurs after the Key Ceremony and is the CA Activation event.

  • Key Activation
  • After a CA is created, it is ready to be put online by the Digi-Sign Digi-CAST2™ Installation Team. This is done by using the certificate repository folder, that contains the files created during the Key Ceremony. For each CA, a request file (.req) and a certificate (.x509) file are generated. The request file (.req), identifies which pre-generated key pair is assigned to the new CA. The certificate (.x509) file is a binary encoding of the Digital Certificate [14] associated with the new CA. Both of these files include a copy of the public key.

    After the Key Ceremony, the request file and the .x509 file are saved to the certificate repository folder maintained on the computer system. The Digi-CAST2™ Installation Team will then complete the process and bring the new CA online.

  • Key Maintenance
  • Once a CA is put online, it must be maintained. Maintenance activities include archiving CA material in a secure storage area, reactivating the CA in the event of a hardware failure, and tracking revoked and suspended certificates. If there is any possibility that the integrity of the individual CA is no longer verifiable, then the integrity of the entire PKI hierarchy to which it belongs is threatened. Reasons for compromise could include violation of the Certificate Practice Statement [26] by the customer, incorrect CA parameters, or loss or misuse of the CA private key. If any of these occur, your organization is responsible for revoking the CA certificate in order to maintain the integrity of the PKI hierarchy.

    Important Note: If a CA’s certificate is revoked during the maintenance phase that CA cannot be re-certified.

  • Key Recertification
  • Every CA is assigned a validity period. During this period, the CA can issue end entity Certificates. A CA cannot issue a certificate with a validity period that extends beyond its own expiration date. End entity certificates typically have a validity period of one year. Consequently, a CA must be re-certified a minimum of one year before its expiration date. Recertification occurs in a separate Key Ceremony. Fir this reason, your organization must appoint a Key Ceremony Administrator and this/these person(s) must participate in the original Key Ceremony conducted by the Key Ceremony Administrator. Using all of the above collateral and experience, this new Key Ceremony Administrator assumes responsibility for tracking the validity periods of all created CAs and for notifying the appropriate personnel when it is time to re-certify a CA.

Samples & Templates

Text needed here

Specification

Preset Certificate Specification Template

PDF [53] The first component in ensuring a properly configured CA is the naming document. Its formal title is the New Issuing Authority Naming Application. This document contains the information necessary to properly configure a CA:

  • Name of the organization responsible for the new CA.
  • Validity period (or operational period) of the new CA.
  • Distinguished Name of the issuing CA.
  • Subject Distinguished Name of the new CA.
  • Certificate extensions and other certificate content information.



After the Digi-CAST2™ Consultant and the customer have defined the Customer’s CA, the
Digi-CAST2™ Consultant will give you a copy of the completed naming document that has
been signed by both the Digi-CAST2™ Consultant and the Customer. You will use the information in the naming document to create the CA. Detailed information about the naming document is available in Chapter 4, "Key Ceremony Preparation".

Key Ceremony Script

1.Purpose

    PDF [53] We have a requirement, that the generation of new RSA keys and creation of new Certification Authorities (CAs) must be witnessed by a third party auditor and appointed witnesses. We must therefore generate fresh keys which have been witnessed in the prescribed manner and use these keys to create new Certification Authorities (CAs).

    The keys we generate today will be new keys, having no existing keys residing on the HSM device we are about to use during this ceremony. There are therefore no existing keys residing in the HSM device should this note be relevant to any party participating in this ceremony.



2.Background

    We use the nCihper Hardware Security Module devices, model: netHSM 500. These devices are certified to FIPS 140-2 level 2 and 3, and level 3 configuration was chosen for the HSM device we are about to use today during this ceremony.

    It is important to note, that the Key Generation and Certificate Signing operations occur entirely within the HSM device which uses a FIPS 140 approved pseudo random-number generator, which is seeded periodically from a random bit-value accumulator fed with an unpredictable input from an electronic noise source.

    The prime number generator used in RSA key pair generation is entirely within the HSM and is covered by FIPS 140.



3.Key Generation and Certificate Signing Control Software

    Cryptographic Operation Control software: HSM device Support Software and Digi-CA™ PKI [30] System, were both written so that together provide the following capabilities:

    1. Instruct an HSM device to "wipe" all keys from its storage.
    2. Instruct an HSM device to generate [n] x 4096 bits RSA key pairs.
    3. Instruct an HSM device to generate [n] x 2048 bits RSA key pairs.
    4. Instruct an HSM device to write those key pairs in an encrypted format to hard disk.
    5. Create and split the private key encryption keys into encrypted sets, stored on individual PIN protected smart cards, such that the private keys could be accessed, reconstructed and re-imported to a (new) HSM device only using any 3 of the 5 cards from a defined card sets.
    6. Copy the encrypted private key to separate removable media for backup purposes. This process is accomplished using the [Red Hat Enterprise Linux 5.0] operating system tools rather than the Cryptographic Operational Control Software.
    7. Instruct an HSM device to Load or Import encrypted RSA key pairs from hard disk.
    8. Instruct an HSM device to mark all private keys held within itself as non-exportable. This is a default limitation when HSM device is configured to operate in FIPS 140-2 level 3 mode.
    9. Combine 3 (of the original 5) smart cards of private key encryption key fragments (components) to produce and encrypt a set of keys on the HSM device.
    10. Instruct HSM device to load a private key and sign a new certificate data.



The software and the procedures were tested to ensure, that the keys were valid, and that the import and export procedures were working as required.

The source code was examined to ensure that its operation was correct.

Key Map Template

PDF [53]


Issue
Date



Device Serial


Subject Dn


Issue Dn


.req
File


.509
File



Validity Period


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Initialization Event

Key Access Component Card Set Configuration

    1. PDF [53] An IBM compatible computer (hereafter referred to as "the computer") was set up in a room providing strict personnel access control, security camera monitoring [and electronic isolation from any computer networks].

    2. The computer has a hard disk which has been pre-prepared with a fresh installation of a [Red Hat Enterprise Linux, version 5.0] operating system, the requisite HSM driver, nToken authentication PCI device, HSM device Support Software and the
    Digi-CA™ PKI System, both acting as the Cryptographic Operation Control Software. The software was tested for correct operation prior to the Key Ceremony by using an HSM reserved for backup purposes.

    3. The Key Access Component Cards are going to be distributed to appointed Key Access Component Holders during a later event of this ceremony. It is however important to note, that Key Access Component Holders are the only holders possessing PIN codes necessary to access the data stored on these smart cards. Before this step can be completed, each appointed Key Access Component Holder must now write down their new PIN code on a dedicated PIN paper sheet and put the PIN paper sheet with the written PIN code into an envelope, indicating their full personal name. Each envelope is to be placed on the Inventory Table and remain not sealed for the duration of the entire Key Ceremony. All attending Witnesses must ensure, that Key Access Component Holders are inserting their PIN Code paper sheets into correct envelopes, that indicate their full personal name.
    Key Ceremony Administrator should now place a sufficient number of empty Key Access Component Cards on top of the envelopes containing PIN Code paper sheets. It is important to note, that the video camera should constantly record all activities related to access to the Key Access Component Cards and envelopes containing PIN Code paper sheets.

    The Key Ceremony Administrator is now going to note the new Name for the newly configured Key Access Component Card Set, the Serial Number of each Key Access Component Card, that is about to be used and the details of each Key Access Component Holder (below) in this script. All attending Key Ceremony Witnesses must ensure, that the date entered into the script, the full personal name of each Key Access Component Holder and the Serial Number of the Key Access Component Card they are about to use is correct. They also must place their signature where indicated (below) in this section of the script.

            Date: …………………………………………

            Key Access Component Card Set
            Name: …………………………………………………………………………………………………………………

            Key Access Component Holder #1
            Full Name: …………………………………………………………………………………………………………………
            Card Serial Number: ……………………………………………………………………………………………

            Key Access Component Holder #2
            Full Name: …………………………………………………………………………………………………………………
            Card Serial Number: ……………………………………………………………………………………………

            Key Access Component Holder #3
            Full Name: …………………………………………………………………………………………………………………
            Card Serial Number: ……………………………………………………………………………………………

            Key Access Component Holder #4
            Full Name: …………………………………………………………………………………………………………………
            Card Serial Number: ……………………………………………………………………………………………

            Key Access Component Holder #5
            Full Name: …………………………………………………………………………………………………………………
            Card Serial Number: ……………………………………………………………………………………………


Witnessing Attendees’ Signatures

  • 4. PDF [53] The first HSM device (designated #1) was removed from production and connected to the computer prior to this ceremony and the event was monitored and supervised by an appointed company’s Head of Security.
  • The Cryptographic Operation Control Software is now about to be used to cause the numbered (in section 3 above) operations to occur in the following sequence: 5.

    During this phase of the Key Generation Ceremony, a new Key Access Component Card Set is created and bound to our HSM device security infrastructure. The card set configuration we choose is as follows:

        a. Total number of smart cards in a card set: 5

        b. Minimum number of smart cards required to access the private key: 3

        c. Minimum number of smart cards required to recreate any lost smart card: 3

        d. Minimum number of smart cards required to recover lost PIN codes: 3

        e. Minimum number of smart cards required to recover a private key: 3



    During this step, one of the HSM Security Administrators present at the ceremony will be requested by the Key Generation Ceremony Administrator to insert his Administrator’s Smart Card into the smart card reader interface of the HSM device in order to authorize the creation of a new Key Access Component Card Set. This is required by the HSM device, which operates in FIPS 140-2 level 3 modes.

    Further during step, each appointed (in previous step) Key Access Component Holder will be requested to actively participate in the ceremony. The Key Generation Ceremony Administrator will require each Key Access Component Holder to separately follow the steps below:

        a. Access their PIN envelope, that were previously placed on the Inventory Table

        b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet

        c. Confirm to memorize their PIN code

        d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table

        e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device

        f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter and confirm their memorized PIN Code.

        g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.
        The above sequence of steps will be repeated for each appointed new Key Access Component Holder.
        All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step.


  • 5. The previous step left the HSM device #1 configured for use with our newly configured Key Access Component Card Set, commonly referred to as Operator Card Set.
  • The new card set will be subsequently used during this ceremony to encrypt and protect access to relevant private keys we are about to generate. The encryption key elements [components] are now stored on each PIN protected Key Access Component Card, which will be required to access newly generated and access protected private keys at any time.

  • 6. The Key Access Component Card Set Configuration is now declared complete.

Controls

PDF [53] During the Key Access Component Card Set Configuration, at least two people from the Key Ceremony Attendees list of personnel were present at all times. No other personnel were permitted access to the room. The Cryptographic Operation Control Software required a PIN code to be entered before the software could communicate with any smart card (holding encryption key component [Key Access Component Card]) used during the Key Access Component Card Set configuration.

5.Generation Event

  • 5.1 Key Generation Ceremony
    • 1. An IBM compatible computer (hereafter referred to as "the computer") was set up in a room providing strict personnel access control, security camera monitoring [and electronic isolation from any computer networks].

      2. The computer has a hard disk which has been pre-prepared with a fresh installation of a [Red Hat Enterprise Linux, version 5.0] operating system, the requisite HSM driver, nToken authentication PCI device, HSM device Support Software and the Digi-CA™ PKI [30] System, both acting as the Cryptographic Operation Control Software. The software was tested for correct operation prior to the Key Generation Ceremony by using an HSM reserved for backup purposes.

      3. The first HSM device (designated #1) was removed from production and connected to the computer prior to this ceremony and the event was monitored and supervised by an appointed company’s Head of Security. The Cryptographic Operation Control Software is now about to be used to cause the numbered (in section 3 above) operations to occur in the following sequence:

      9, 2, 4, 3, 4, 6, 6, 6.

      During this step, the Key Generation Ceremony Administrator will capture and store any relevant informational output produced on the computer screen by the Cryptographic Operation Control Software in the Key Map Document.

      Also during this step, the Key Generation Ceremony Administrator will require any 3 (three) Key Access Component Holders from the previously created Key Access Component Card Set, to separately follow the steps below:

          a. Access their PIN envelope, that were previously placed on the Inventory Table

          b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet

          c. Confirm to memorize their PIN code

          d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table

          e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device

          f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter their memorized PIN Code.

          g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.
          The above sequence of steps will be repeated for the number of Key Access Component Holders that are selected by the Key Generation Ceremony Administrator.
          All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step.

Controls & Generation Events

Key Generation Ceremony

  • 4. PDF [53] The previous step left the HSM device #1 configured for use with our newly generated keys.
    • The encrypted private keys are now stored securely within an encrypted key repository on the hard disk within the computer, as well as on the removable media. Only the HSM device holding decryption keys for the particular key repository is able to decrypt the repository data. Further decryption process is also required to bring keys to an online state. The latter applies to particular keys, that we protected with additional encryption key during the key generation phase.

      The encryption key elements [components] are stored on several PIN protected smart cards, herein referred to as "Key Access Component Cards", which are required to access these keys at any time. The smart cards are currently visible on the Inventory Table and during the later phase of this ceremony will be distributed to the Key Access Component Holders, who are the only holders possessing PIN codes necessary to access the data stored on these smart cards.

      We note, that there is no need to delete our encrypted keys from the hard disk within the computer as these keys are strongly encrypted by the HSM device and additional encryption key, that was divided into key elements (components) within a key set. If the key repository data was stolen, it would be useless without the HSM decryption key and additional encryption key elements (components) distributed to Key Access Component Holders inside the PIN protected Key Access Component Cards. The encrypted keys stored within the repository are in offline state and the computer with the hard drive storing the encrypted repository data will be kept safe in an isolated room with strict personnel and network access controls in place as well as video camera monitoring maintained 24 hours per day throughout the year.


  • 5. We will now generate checksum bytes, that will uniquely identify the encrypted private key data stored both on the hard disk and on the backup media disks.
    • For this purpose, we will use an Operating System tool [sha1sum]. The Key Ceremony Administrator will now sequentially, using the Key Map Document, read the file names and file system paths for each generated private key, generate the checksum bytes calculated on private keys stored inside the repository as well as on the backup media and note the checksum byte strings (below) in this script.

      All witnesses attending this part of the ceremony must ensure, that the date entered into this script is correct and the checksum values presented on the computer screen upon sequential execution of the checksum calculation commands, that are performed on private key data stored inside the repository as well as on the backup media, and the values written below by the Key Ceremony Administrator, exactly match. They also must place their signatures where indicated (below) in this section of the script.

          Date: …………………………………………

          Key 1
          Common Name: ………………………………………………………………………………………………………
          Checksum: …………………………………………………………………………………………………………………

          Key 2
          Common Name: ………………………………………………………………………………………………………
          Checksum: …………………………………………………………………………………………………………………

          …

          Key N
          Common Name: ………………………………………………………………………………………………………
          Checksum: …………………………………………………………………………………………………………………
          Witnessing Attendees’ Signatures:

Generation Events

Key Generation Ceremony

  • 6. PDF [53] The removable media disks holding backup copies of our keys will now be separated placed into sealed envelopes and sent to be held at separate bank deposit facilities immediately after this ceremony.
    • We note, that each media disk was removed from this computer sequentially for storage purposes in each of the indicated storage facilities.


  • 7. The Key Generation Ceremony is now declared complete.


Controls

    During the Key Generation Ceremony, at least two people from the Key Ceremony Attendees list of personnel were present at all times. No other personnel were permitted access to the room. The Cryptographic Operation Control Software required a PIN code to be entered before the software could communicate with any smart card (holding encryption key component [Key Access Component Card]) used during the Key Generation Ceremony.


6. Signing Event

  • 6.1 Root CA Signing
    • 1. An IBM compatible computer (hereafter referred to as "the computer") was set up in a room providing strict personnel access control, security camera monitoring [and electronic isolation from any computer networks].


      2. The computer has a hard disk which has been pre-prepared with a fresh installation of a [Red Hat Enterprise Linux, version 5.0] operating system, the requisite HSM driver, nToken authentication PCI device, HSM device Support Software and the
      Digi-CA™ PKI [30] System, both acting as the Cryptographic Operation Control Software. The software was tested for correct operation prior to the Key Ceremony by using an HSM reserved for backup purposes.


      3. The hard disk installed in the computer contains an encrypted key repository, from which we will load necessary private keys into a securely protected operational memory of our HSM device.


      4. The first HSM device (designated #1) was removed from production and connected to the computer prior to this ceremony and the event was monitored and supervised by an appointed company’s Head of Security. The Cryptographic Operation Control Software is now about to be used to cause the numbered (in section 3 above) operations to occur in the following sequence: 10.

      During this step, the Key Ceremony Administrator, using the Cryptographic Operation Control Software, will create new self-signed Root CA Certificate and assign it to a dedicated private key that was previously generated during this ceremony.

      To complete this process, the Key Ceremony Administrator will use a Naming Document, that contains the details of the new Root CA Certificate we are about to sign, to create a certificate profile configuration file, containing various certificate related information such as: Subject Distinguished Name, Validity Period, Signature Algorithm, Certificate Serial Number and Certificate extensions. The certificate profile configuration file will be used by the Cryptographic Operation Control Software to create the new Root CA certificate.

      All attending Witnesses must ensure, that the certificate details entered into the certificate profile configuration file by the Key Ceremony Administrator, match the details contained in the Naming Document used during this ceremony. The new Root CA Certificate details must be taken from the section of the Naming Document specifically dedicated for the correct Root CA, for which the Root CA Certificate is created.

      Key Ceremony Administrator will capture and store during this step any relevant informational output produced on the computer screen by the Cryptographic Operation Control Software in the Key Map Document.
      Upon directing the Cryptographic Operation Control Software to sign the new Root CA Certificate, the dedicated private key will need to be loaded to the HSM securely protected operational memory.


Component Holders

Root CA Signing

PDF [53] 4. Since the private key we are about to use is encrypted and access protected, the Key Ceremony Administrator will require any 3 (three) Key Access Component Holders from the previously created Key Access Component Card Set, to separately follow the steps below:

    a. Access their PIN envelope, that were previously placed on the Inventory Table

    b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet

    c. Confirm to memorize their PIN code

    d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table

    e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device

    f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter their memorized PIN Code.

    g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.

The above sequence of steps will be repeated for the number of Key Access Component Holders, that are selected by the Key Ceremony Administrator.

All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step.

Furthermore, all Witnesses must ensure, that the correct private key is used during this step. This can be achieved by cross-checking whether the private key identifier file name along with the file system path, are both entered correctly by the Key Ceremony Administrator in the command prompt. These must match the private key details stored in the Key Map Document. The private key should be dedicated for use only with the new Root CA we created today hence the cross-check.


5. The previous step left the private key used to sign the newly created Root CA Certificate offline. It also permanently associated that private key with the new Root CA we created.


6. The Root CA Signing is now declared complete.

Subordinate CA Signing

    1. PDF [53] An IBM compatible computer (hereafter referred to as "the computer") was set up in a room providing strict personnel access control, security camera monitoring [and electronic isolation from any computer networks].


    2. The computer has a hard disk which has been pre-prepared with a fresh installation of a [Red Hat Enterprise Linux, version 5.0] operating system, the requisite HSM driver, nToken authentication PCI device, HSM device Support Software and the Digi-CA™ PKI [30] System, both acting as the Cryptographic Operation Control Software. The software was tested for correct operation prior to the Key Ceremony by using an HSM reserved for backup purposes.


    3. The hard disk installed in the computer contains an encrypted key repository, from which we will load necessary private keys into a securely protected operational memory of our HSM device.


    4. The first HSM device (designated #1) was removed from production and connected to the computer prior to this ceremony and the event was monitored and supervised by an appointed company’s Head of Security. The Cryptographic Operation Control Software is now about to be used to cause the numbered (in section 3 above) operations to occur in the following sequence: 10.

    During this step, the Key Ceremony Administrator, using the Cryptographic Operation Control Software, will create new Subordinate CA and assign it to a dedicated private key that was previously generated during this ceremony. The newly created Subordinate CA will be signed by the Root CA that was created earlier during this ceremony.

    To complete this process, the Key Ceremony Administrator will use a Naming Document, that contains the details of the new Subordinate CA we are about to sign, to create a certificate profile configuration file, containing various certificate related information such as: Subject Distinguished Name, Validity Period, Signature Algorithm, Certificate Serial Number and Certificate extensions. The certificate profile configuration file will be used by the Cryptographic Operation Control Software to create the new Subordinate CA certificate.

    All attending Witnesses must ensure, that the certificate details entered into the certificate profile configuration file by the Key Ceremony Administrator, match the details contained in the Naming Document used during this ceremony. The new Subordinate CA Certificate details must be taken from the section of the Naming Document specifically dedicated for the correct Subordinate CA, for which the Subordinate CA Certificate is created.
    Key Ceremony Administrator will capture and store during this step any relevant informational output produced on the computer screen by the Cryptographic Operation Control Software in the Key Map Document.

Key Access Component Holders

  • PDF [53] Upon directing the Cryptographic Operation Control Software to sign the new Subordinate CA Certificate, the private key of the Root CA will need to be loaded to the HSM securely protected operational memory.
    • Since the private key of the Root CA we are about to use is encrypted and access protected, the Key Ceremony Administrator will require any 3 (three) Key Access Component Holders from the previously created Key Access Component Card Set, to separately follow the steps below:

        a. Access their PIN envelope, that were previously placed on the Inventory Table

        b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet

        c. Confirm to memorize their PIN code

        d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table

        e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device

        f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter their memorized PIN Code.

        g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.



      The above sequence of steps will be repeated for the number of Key Access Component Holders, that are selected by the Key Ceremony Administrator.

      All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step. Furthermore, all Witnesses must ensure, that the correct Root CA private key is used during this step. This can be achieved by crosschecking whether the private key identifier file name along with the file system path, are both entered correctly by the Key Ceremony Administrator in the command prompt. These must match the Root CA private key details stored in the Key Map Document. The correct Root CA private key should be used hence the crosscheck.


  • 5. The previous step left the Root CA private key used to sign the newly created Subordinate CA Certificate offline.
  • It also permanently associated an existing private key, that was generated earlier during this ceremony with the new Subordinate CA we created.

  • 6. The Subordinate CA Signing is now declared complete.

    • Controls

      During the Signing Event, at least two people from the Key Ceremony Attendees list of personnel were present at all times. No other personnel were permitted access to the room. The Cryptographic Operation Control Software required a PIN code to be entered before the software could communicate with any smart card (holding encryption key component [Key Access Component Card]) used during the Signing Event.

Distribution Event

  • Key Access Component Card Distribution
    • PDF [53] During this phase of the ceremony, the Key Ceremony Administrator will request each Key Access Component Card Holder to place their Key Access Component Cards in their PIN envelopes place the envelopes sealed on the Inventory Table.


  • Key Access Component Holder Document Signing
    • During this phase of the ceremony, the Key Ceremony Administrator will request each Key Access Component Holder to sign the Key Access Component Holder Document indicating, that they have read, understand and agree to follow the duties and responsibilities of a Key Access Component Holder and that they have witnessed the signature of all the other Key Access Component Holders.


  • Key Map Document Signing
    • During this phase of the ceremony, all attending Witnesses will sign the Key Map Document indicating, that this was the actual document used during the ceremony and it was completed with accordance to the script.


  • Naming Document Signing
    • During this phase of the ceremony, all attending Witnesses will sign the Naming Document indicating, that this was the actual document used during the ceremony with accordance to the script to create our new CA hierarchy.


  • Attestation Letter Signing
    • During this phase of the ceremony, all attending Witnesses will sign Attestation Letters indicating, that they read the script, observed the ceremony and attest, that the ceremony was performed as described in the script.


  • Key Ceremony Script Signing
    • During this phase of the ceremony, all attending Witnesses will sign the Key Ceremony Script document indicating, that this was the actual document used during the ceremony w to create our new CA hierarchy.


  • Signature Certification
    • During this phase of the ceremony, the Key Ceremony Administrator will direct the official representative of the Government, to notarize (certify signatures on) the witnesses’ Attestation Letters.


Conclusion

8. Key Ceremony Conclusion

  • PDF [53] All copies of the signed Key Ceremony Script are now going to be placed in the Archive Folder.
  • All copies of Attestation Letters are now going to be placed in the Archive Folder.
  • All copies of Key Access Component Holder Documents are now going to be placed in the Archive Folder.
  • The Key Map Document is now going to place in the Archive Folder.
  • The Naming Document is now going to place in the Archive Folder.
  • The camera operator will now stop the recording and all Video Recordings are now going to be placed in the Archive Folder.
  • The Archive Folder is now going to be sealed.
  • The Head of Security will now take the sealed Archive Folder and place it in a safe in a dedicated access protected cabinet.
  • The Head of Company’s Security will now direct all Key Access Component Holders to take their envelopes containing PIN Code paper sheets and Key Access Component Cards and place these securely in a safe in separate access protected cabinets.
  • All hardware equipment, including the HSM device and the computer will be taken from this room after this ceremony and installed back in the production environment in a dedicated access protected and video camera monitored room.
  • After the ceremony is complete, the Digi-Sign Digi-CAST2™ installation team will proceed to the CA Activation event, which will be monitored and supervised by the Head of Company’s Security. The CA Activation Event is not a part of this ceremony and may be performed at a different date.
  • The Key Ceremony is now declared complete.



9. Key Ceremony Attendees Present

Name Title Company Signature

[This page printed blank to allow notes to be made]

Component Holder Document

Appendix V – Key Access Component Holder Document

PDF [53] I am:

    CA Organization Shareholder’s Name:

    _______________________________________________________________________
    CA Owner Organization Name:

    ___________________________________________________________
    CA Owner Organization’s Address:

    ___________________________________________________________
    CA Owner Organization’s Telephone Number:

    ___________________________________________________________

        Passport:
        ID Card:
        Other (specify___________)
        No:____________________


I confirm that I am in receipt of the following Component(s):

Description Details:

_________________________________________________________________________

_________________________________________________________________________


I confirm that:

      I have understand that I am an official Component Receipt Shareholder.

      I must keep my Component information secret.

      I will only reveal my Component information at scheduled Key Ceremony events.

Under penalties of perjury, I declare to the best of my knowledge and belief, that the information I have provided is true, correct, and complete.

Signature: ___________________________________ Date: ____________________


I attest that:

      I have validated the identity of this Key Access Component Holder

      Under penalties of perjury, I declare to the best of my knowledge and belief, that the information I have provided is true, correct, and complete.

      Notary Signature: _____________________________ Date:____________________

Attestation Letter

Appendix VI – Attestation Letter

PDF [53] I am:

      A Certified Public Notary
      An Attorney
      An Official Public witness


    Name:

    _______________________________________________________________________

    Organization Name:

    ___________________________________________________________

    Organization Address:

    ___________________________________________________________

    Telephone Number: ___________________________________________________________


    Professional License and/or Association Number(s):_________________________

This letter of attestation is being provided on behalf of the following entity:

    CA Owner Organization’s Name:

    ________________________________________________________________

    CA Owner Organization’s Address:

    ________________________________________________________________

    CA Owner Organization’s Telephone Number:

    ________________________________________________________________



I attest that:

      I have read the attached Key Ceremony Script
      I have verified the identity of the Digi-CAST2™ Key Ceremony Administrator
      I have validated the identity of each witness attendee
      I have validated the identity of each shareholder attendee
      I have validated the identity of each observer attendee
      I have observed the Key Ceremony
      I have observed all the attendees of the Key Ceremony
      The Key Ceremony was performed as described in the attached Script
      I have certified the signed Component Receipt Documents
      I have certified the sealed Archive Folder



Under penalties of perjury, I declare to the best of my knowledge and belief, that the information I have provided is true, correct, and complete.

Signature: ___________________________________ Date: ____________________

Notary Signature: _____________________________ Date: ____________________


Appendix III – Entry/Exit Log

      CA Owner Organization’s Name:

      ________________________________________________________________

      CA Owner Organization’s Address:

      ________________________________________________________________

      CA Owner Organization’s Telephone Number:

      ________________________________________________________________


WebTrust

Introducing WebTrust

For compliance reasons, certain CA systems must prepare and document a complete set of WebTrust policies and procedures. Trusted Third Party [TTP] Certificate Authority [CA] (also known as 'Trust Centre') organisations and specific Government projects are two examples where WebTrust policies and procedures may be required in advance of conducting the WebTrust Audit.

There are typically three phases of the WebTrust implementation and these are sub divided and described in the following sub sections:

WebTrust Assurance Process


The CA’s management will make assertions along the following lines:

Management has assessed the controls over its CA operations. Based on that assessment, in ABC Certification Authority, Inc. (ABC-CA) Management’s opinion, in providing its certification authority (CA) services at [location], ABC-CA, during the period from [Month, day, year] through [Month, day, year]:

  • Disclosed its key and certificate life cycle management business and information privacy practices and provided such services in accordance with its disclosed practices

  • Maintained effective controls to provide reasonable assurance that:

    • Subscriber information was properly authenticated (for the registration activities performed by ABC-CA); and


    • The integrity of keys and certificates it managed was established and protected throughout their life cycles


  • Maintained effective controls to provide reasonable assurance that:

    • Subscriber and relying party information was restricted to authorized individuals and protected from uses not specified in the CA's business practices disclosure;


    • The continuity of key and certificate life cycle management operations was maintained; and


    • CA systems development, maintenance, and operations were properly authorized and performed to maintain CA systems integrity based on the WebTrust for Certification Authorities criteria.


For an initial representation, the historical period covered should be at least two months or more as determined by the practitioner. For established CAs and CA functions, two months may be quite sufficient, while for new CAs and CA functions, the practitioner may believe that a longer initial period would be more appropriate. For subsequent representations, the period covered should begin with the end of the prior period, to provide continuous representation. Reports should be issued at least every 12 months. In some situations, given the business needs or expectations of relying parties, the practitioner may believe a shorter subsequent period would be more appropriate.

To have a basis for such assertions, the CA’s management should have made a risk assessment and implemented appropriate controls for its CA operations. The WebTrust for Certification Authorities criteria and illustrative controls provide a basis for a risk assessment and a minimum set of CA controls.

An independent, objective, and knowledgeable practitioner will perform tests of these representations under professional standards and provide a professional opinion, which adds to the credibility of management’s representations.

Comparison with Service Auditor Reports


Comparison of a WebTrust for Certification Authorities Examination With Service Auditor Reports:

Professional standards currently exist for auditors to report on controls of third-party service providers (a service auditor’s engagement). Guidance for these engagements is set out in the Statement on Auditing Standards [SAS] No. 70 [SAS-70], Service Organizations, as amended.

WebTrust for Certification Authorities engagement differs from a service auditor’s engagement in a number of ways, including the following:

  • Purpose. WebTrust for Certification Authorities provides a new framework for reporting activities of CAs through auditor communication to interested parties, including business partners and existing or potential customers. SAS-70 was designed for auditor-to-auditor communication to assist the user auditor in reporting on the financial statements of a customer of the service organization.

  • Target of evaluation. WebTrust for Certification Authorities was designed specifically for the examinations of CA business activities. Service auditor reports were designed for service organizations in general.

  • Type of engagement. WebTrust for Certification Authorities requires reporting on compliance with the WebTrust Principles and Criteria for Certification Authorities. Service auditor reports were designed for reporting on the design and existence of controls and the effective operation of those controls when the report covers a period of time.

  • Examination standards. WebTrust for Certification Authorities follows the Statements on Standards for Attestation Engagements (SSAEs). Service auditor reports follow generally accepted auditing standards.

  • Coverage of activities. WebTrust for Certification Authorities requires coverage of specific areas as defined herein, including CA business practices disclosure, service integrity (including key and certificate life cycle management activities), and CA environmental controls. Service auditor reports were designed for reporting upon controls related to financial information.

  • Linkage to authoritative standards. WebTrust for Certification Authorities provides uniform rules derived from the draft ANSI X9.79 standard (which is intended to be submitted to the International Organization for Standardization [ISO] for international standardization). Standards underlying service auditor reports do not specify the control objectives that must be covered by the report.

  • Period of coverage of review. WebTrust for Certification Authorities encourages continuous coverage from the point of initial qualification and requires continuous coverage to retain the seal. Qualification after compliance can be tested over a minimum two-month period, with updates over a specified period (currently one-year maximum). Service auditor reports cover a period of time specified by the service organization, but do not require continuous coverage.

In addition, this approach maintains consistency in the professional standards used for the Suitable Trust Services Criteria and Illustrations.

WebTrust Seal

Obtaining the WebTrust Seal

To obtain the WebTrust seal of assurance, the CA must meet all the WebTrust for Certification Authorities principles as measured by the WebTrust for Certification Authorities criteria associated with each of these principles. In addition, the entity must engage a practitioner to provide the WebTrust service, and obtain an unqualified report from such practitioner.

Keeping the WebTrust Seal

Once the seal is obtained, the CA will be able to continue displaying it on its Web site provided the following are performed:

  • The CA’s WebTrust practitioner updates his or her assurance examination of the assertion on a regular basis. The CA must continue to obtain an unqualified report from such practitioner. The interval between such updates will depend on matters such as the following:

    • The nature and complexity of the CA’s operations


    • The frequency of significant changes to the CA’s operations


    • The relative effectiveness of the entity’s monitoring and change-management controls for ensuring continued conformity with the applicable WebTrust for Certification Authorities criteria as such changes are made


    • The practitioner’s professional judgment


  • For example, an update may be required more frequently for a CA that is expanding operations, changing extensively and rapidly, or issuing high-assurance certificates that are used for very sensitive transmissions or high-value transactions, as compared to a CA that issues few certificates and has a relatively stable operation. In no event should the interval between updates exceed 12 months; this interval often may be shorter. For example, in the situation of a start-up CA or CA function, it may be more appropriate that the initial examination period be established at 3 months, with the next review being performed 6 months after the WebTrust seal for CAs is awarded, thereafter moving to a 12-month review cycle. To provide continuous coverage and retain the seal, the period covered for update reports should begin with either the end of the prior period or the start of the period in the initial report.

  • During the period between updates, the CA undertakes to inform the practitioner of any significant changes in its business policies, practices, processes, and controls, particularly if such changes might affect the CA’s ability to continue meeting the WebTrust Principles and Criteria for Certification Authorities, or the manner in which they are met. Such changes may trigger the need for an assurance update or, in some cases, removal of the seal until an update examination by the practitioner can be made. If the practitioner becomes aware of such a change in circumstances, he or she determines whether the seal needs to be removed until an update examination is completed and the updated auditor’s report is issued.


WebTrust Seal Management



The WebTrust seal of assurance for the CA will be managed by a seal manager along the following lines:

  • Upon becoming a WebTrust licensee, the WebTrust practitioner obtains a registration number (ID and password) from the WebTrust licensing authority. With this the practitioner can issue a WebTrust seal to the CA.

  • When the practitioner is prepared to issue a WebTrust seal, he or she accesses the WebTrust secure server system. Upon payment of the registration fee, the practitioner receives passwords and IDs unique to the engagement. The seal manager issues these to the practitioner in pairs. One set allows the practitioner to read and write to the secure server (see below) and the other permits the CA to preview the presentation.

  • The practitioner prepares a draft of the practitioner’s report and provides it along with management’s assertions for posting to the preview site.

  • The seal manager then delivers the seal to the CA with the appropriate links to the preview site. Notification of delivery is provided to the practitioner.

  • When the practitioner and CA have agreed that the seal should become active, the practitioner notifies the seal manager to transfer the information from the preview site to the active WebTrust site and provides the appropriate expiration date.

  • The seal remains valid for the period provided by the practitioner plus a one-month grace period, unless removed for cause. The one-month period is to allow sufficient time to complete the engagement and other open items. For example, if the seal expires on June 30, 20XX, the practitioner has 30 days to complete open items and prepare new documents for posting with the seal manager. The subsequent examination period begins July 1, 20XX

  • If the practitioner determines that the seal should be removed from the CA’s Web site, the practitioner will immediately notify the CA and request that the seal be removed from the CA’s site. The practitioner will then notify the seal manager to remove all the relevant information and to replace it with a statement that the WebTrust seal for this site is no longer valid.

  • The seal manager will notify the practitioner 30 days prior to expiration that the seal needs to be renewed. The seal manager may revoke seals if the registration fee for the seal is unpaid or for other sufficient cause.


WebTrust Seal Authentication



To verify whether the seal displayed on a CA's Web site is authentic, the customer can:

  • Click on the seal, which links the customer through a secure connection to a WebTrust seal verification page hosted by the seal manager. It identifies the CA and confirms that the CA is entitled to display the WebTrust seal. It also provides links to the appropriate principle(s) (that is, the WebTrust for Certification Authorities principles) and other relevant information

  • Access the list of entities that have received a WebTrust seal; the list is maintained by the seal manager at www.webtrust.org/abtseals.htm [54]. A CA is registered on this list when the seal is issued


WebTrust Principal 1

WebTrust for Certification Authorities Principles

To be understandable to the ultimate users—the subscriber and relying party—the following principles have been developed with the relying party in mind, and, as a result, are intended to be practical and non-technical in nature.

Principle 1: CA Business Practices Disclosure

  • The first principle is—The certification authority discloses its key and certificate life cycle management business and information privacy practices and provides its services in accordance with its disclosed practices.

  • The CA must disclose its key and certificate life cycle management business and information privacy practices. Information regarding the CA’s business practices should be made available to all subscribers and all potential relying parties, typically by posting on its Web site. Such disclosure may be contained in a certificate policy [CP], certification practice statement [CPS], or other informative materials that are available to users (subscribers and relying parties).


WebTrust Principle 2

Service Integrity

The second principle is—The certification authority maintains effective controls to provide reasonable assurance that:

  • Subscriber information was properly authenticated (for the registration activities performed by ABC-CA).

  • The integrity of keys and certificates it manages is established and protected throughout their life cycles.

Effective key management controls and practices are essential to the trustworthiness of the public key infrastructure. Cryptographic key management controls and practices cover CA key generation; CA key storage, backup, and recovery; CA public key distribution (especially when done in the form of self-signed “root” certificates); CA key escrow (optional); CA key usage; CA key destruction; CA key archival; the management of CA cryptographic hardware through its life cycle; and CA-provided subscriber key management services (optional). Strong key life cycle management controls are vital to guard against key compromise that can damage the integrity of the public key infrastructure.

The user certificate life cycle is at the core of the services provided by the CA. The CA establishes its standards and practices by which it will deliver services in its published CPS and CPs. The user certificate life cycle includes the following:

  • Registration (that is, the identification and authentication process related to binding the individual subscriber to the certificate)

  • The renewal of certificates (optional)

  • The rekey of certificates

  • The revocation of certificates

  • The suspension of certificates (optional)

  • The timely publication of certificate status information (through certificate revocation lists or some form of online certificate status protocol)

  • The management of integrated circuit cards (ICCs) holding private keys through their life cycle (optional)



Effective controls over the registration process are essential, as poor identification and authentication controls jeopardize the ability of subscribers and relying parties to rely on the certificates issued by the CA. Effective revocation procedures and timely publication of certificate status information are also essential elements, as it is critical for subscribers and relying parties to know when they are unable to rely on certificates that have been issued by the CA.

WebTrust Principle 3

CA Environmental Controls

The third principle is—The certification authority maintains effective controls to provide reasonable assurance that:

  • Subscriber and relying party information is restricted to authorized individuals and protected from uses not specified in the CA’s business practices disclosure

  • The continuity of key and certificate life cycle management operations is maintained

  • CA systems development, maintenance, and operation are properly authorized and performed to maintain CA systems integrity

The establishment and maintenance of a trustworthy CA environment is essential to the reliability of the CA’s business processes. Without strong CA environmental controls, strong key and certificate life cycle management controls are severely diminished in value. CA environmental controls include CPS and CP management, security management, asset classification and management, personnel security, physical and environmental security of the CA facility, operations management, system access management, systems development and maintenance, business continuity management, monitoring and compliance, and event journaling.

WebTrust for Certification Authorities Criteria


To provide more specific guidance on meeting the WebTrust for Certification Authorities principles, the WebTrust for Certification Authorities criteria have been developed. These provide a basis against which a CA can make a self-assessment of its conformity with the criteria, and a consistent set of measurement criteria for practitioners to use in testing and evaluating CA practices.

The WebTrust for Certification Authorities criteria are presented under the three principles listed above (Principle 1, CA Business Practices Disclosure; Principle 2, Service Integrity, including key and certificate life cycle management controls; and Principle 3, CA Environmental Controls.

Each principle contains a series of criteria that the CA’s management asserts it has achieved. Depending on the scope of services provided by the CA, a number of the criteria may not be applicable. Criteria considered optional, depending on whether the CA provides the related services, are key escrow, certificate renewal, certificate suspension, the use of integrated circuit cards (ICCs), and the provision of subscriber key management services. If any of these services are provided by the CA, the criteria are applicable and must be tested by the practitioner. If any of these services are not provided by the CA, the criteria are not applicable and no modification of the standard report is necessary. In some situations, some RA services may be performed by another party that is not controlled by the CA, and therefore those activities are not included in the examination of the CA. In these circumstances the standard report should be modified to specify the exclusion of the specific RA activities from the scope of the examination.

This may be accomplished by reference to the CA’s business practice disclosures in which the CA specifies which RA activities it does not control. In all instances some RA activities will be performed by the CA and should be tested by the practitioner for compliance with the controls disclosed under Principle 1 and the criteria specified in Principle 2. In performing a WebTrust for Certification Authorities engagement, the practitioner must gain an understanding of the CA’s business model and services provided to determine which control criteria may not be applicable. For each of the disclosure and control criteria, there is a detailed list of illustrative disclosures and control procedures that might be followed by the CA to meet the related criteria. The illustrative disclosures and controls do not necessarily need to be in place for a criterion to be met in a given business circumstance and alternatives may be sufficient.

The CA Business Practices Disclosure criteria were derived primarily from the Internet Engineering Task Force’s (IETF) Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices FrameworkRequest For Comments Draft (RFC 2527), which has been incorporated into Annex A of the draft ANSI X9.79 standard. For specific key and certificate life cycle management (Principle 2) and CA environmental illustrative controls (Principle 3), in which the CA’s implemented controls may vary depending on the CA’s business practices, such illustrative controls refer to specifically required CA business practices disclosures included in Principle 1 [55].


Source URL: http://www2.digi-sign.com/compliance

Links:
[1] https://www.digi-sign.com/downloads/download.php?id=digi-ca-pdf
[2] http://www2.digi-sign.com/digi-ca
[3] http://www2.digi-sign.com/compliance/list+standards
[4] http://www2.digi-sign.com/certificate+authority
[5] http://www2.digi-sign.com/en/digi-cast
[6] http://www2.digi-sign.com/http
[7] http://www2.digi-sign.com/electronic+identification
[8] http://www2.digi-sign.com/en/about/announcements/qualified+certificates
[9] http://www2.digi-sign.com/service/digi-cast
[10] http://www2.digi-sign.com/compliance/introduction
[11] http://www2.digi-sign.com/href
[12] http://www2.digi-sign.com/digi-ca/time+stamp
[13] http://www2.digi-sign.com/two+factor+authentication
[14] http://www2.digi-sign.com/digital+certificate
[15] http://www2.digi-sign.com/digi-id
[16] http://www2.digi-sign.com/digi-ca/administrator/online+certificate+status+protocol
[17] http://www2.digi-sign.com/digi-ca/administrator/time+stamp
[18] https://www.digi-sign.com/downloads/download.php?id=digi-bill-pdf
[19] http://www2.digi-sign.com/compliance/cwa+15580
[20] http://www2.digi-sign.com/compliance/cwa+15588
[21] http://www2.digi-sign.com/compliance/cwa+15581
[22] http://www2.digi-sign.com/compliance/cwa+15582
[23] http://www2.digi-sign.com/compliance/etsi/101+861
[24] http://www2.digi-sign.com/compliance/etsi/102+023
[25] http://www2.digi-sign.com/compliance/cwa+15579
[26] http://www2.digi-sign.com/repository/certificate+practice+statement
[27] https://www.digi-sign.com/downloads/download.php?id=cio-digi-cast-pdf
[28] http://www2.digi-sign.com/compliance/iso/27001
[29] https://www.digi-sign.com/downloads/download.php?id=digi-cast-pdf
[30] http://www2.digi-sign.com/public+key+infrastructure
[31] http://www2.digi-sign.com/service/digi-cast/asset+management
[32] http://www2.digi-sign.com/service
[33] http://www2.digi-sign.com/compliance
[34] mailto:adlinh@cio.gov.bh
[35] mailto:aabualfath@cio.gov.bh
[36] mailto:smalkhalifa@cio.gov.bh
[37] mailto:osamarf@cio.gov.bh
[38] mailto:kaljalahma@cio.gov.bh
[39] mailto:cssoshg@cio.gov.bh
[40] mailto:alghatamhe@cio.gov.bh
[41] mailto:aljassimk@cio.gov.bh
[42] mailto:malamer@cio.gov.bh
[43] mailto:alothmank@cio.gov.bh
[44] mailto:soudbah@cio.gov.bh
[45] mailto:elhama@cio.gov.bh
[46] mailto:monamj@cio.gov.bh
[47] mailto:yashoor@cio.gov.bh
[48] mailto:alshamyah@cio.gov.bh
[49] mailto:razanaak@cio.gov.bh
[50] mailto:aalmahmood@cio.gov.bh
[51] http://www2.digi-sign.com/ssl+certificate
[52] https://www.digi-sign.com/downloads/download.php?id=digi-ca-admin-pdf
[53] http://www2.digi-sign.com/downloads/digi-ca-admin-manual
[54] http://www.webtrust.org/abtseals.htm
[55] http://www2.digi-sign.com/en/digi-cast/webtrust/first+principal