Smart Meters Programme Schedule 4.1

Transcription

1 Smart Meters Programme Schedule 4.1 (Contractor Solution) (SMKI version) V1.1 1

2 Schedule 4.1 (Contractor Solution) This Schedule 4.1 (Contractor Solution) is formed of the following parts: Part A Introduction 3 Part B Background / Context 3 Part C SMKI Solution Overview 4 Part D SMKI Implementation and Project Management 15 Part E Staff Capability and Capacity 15 Part F Organisational Ability and Supply Chain 16 Part G The Recovery Process 18 Part H RA Management and RA Agents 20 Part I Certificate Issuance Performance Metrics 21 Part J tscheme Compliance 21 Part K Testing 22 Part L Service Management 26 V1.1 2

3 Part A Introduction 1 This schedule sets out the Contractor Solution to meeting the DCC Requirements for SMKI. 2 The Contractor Solution shall deliver the requirements set out in Schedule 2.1. Part B Background / Context The SMKI service is at the absolute centre of a successful delivery of not only the DCC s obligations to the DECC but also in the total success of the entire end to end ecosystem. Scale PKI is a mature technology; however the SMKI Service needs to operate at a scale that is rare in the market. Over recent years PKI has experienced a renaissance being ideally suited to large projects involving device authentication such as this. The leap for a provider to move from designing and operating a service for hundreds of thousands of certificates to millions is significant and requires careful design and experience to be able to provide credible commitment. BT / Symantec have the experience to provide services on a similar scale to what is required for this service. We have provided a reference within our proposal where we deliver around xxxx certificates per year to a single project; therefore we know how to design solutions to meet the scale required for the successful rollout of the SMKI project. Operational experience This service must be reliable and robust and the consequences of failure would be significant. From a field engineer unable to install a Smart Meter in a consumer s home because there is a problem with certificates, to a large scale breach affecting a Utility s brand in the marketplace and damaging customer confidence, this project is significant. Any damage to a Utility s commitment to secure client information would have economic impact and have a damaging effect on confidence in the overall Smart Meter program. The Smart Grid is a key part of the Critical National Infrastructure and must be protected and maintained at all times. Cost and green benefits associated with delivering these services to Consumers could be compromised through failure. Proven maturity and experience in the selected provider of this service is therefore a key factor to ensure these risks are mitigated. A strong history of delivering mission critical Managed PKI Operations to demanding service levels and the experience to implement the solutions using Best Practice Standard in line with what is currently being provided to existing clients is what the BT/Symantec proposal brings to DCC and provides confidence in a selection of the service. Pro-Active Project Communications V1.1 3

4 There is no doubt that for a project of this size and complexity, the required timeframes and deliverables are very aggressive. BT/ Symantec have already demonstrated through the pre-tender process, the desire to be open and to share our joint knowledge and collaborate based on experience that will both improve the end service and ensure the timeframes are achievable. This needs to be a partnership between all stakeholders to ensure success and this is the spirit and landscape in which BT and Symantec wish to conduct this relationship now and into the years to come. There is no desire to promise much, and hope the absolute desire is to deliver and delight and this is critical to ensure success for all involved. Part C 1 Overview SMKI Solution Overview The BT/Symantec solution draws upon the strengths and capabilities of both organisations. The proposed solution has the Symantec PKI Platform (SPP) at its core. The SPP will hosted in two of BT s secure UK data centres and be operated and managed by BT s existing PKI service operations team in the UK, which is staffed by xxxx personnel and has 15 years experience of providing managed PKI solutions to customers. 2 Symantec PKI Platform As a robust PKI solution, the Symantec PKI Platform provides the same rich functionality and robust architecture that Symantec employs for the thousands of customers that use its other managed PKI services. The SPP platform issues some xxxx certificates per annum with xxxx incremental certificates being added per annum. The Symantec PKI Platform: Is highly scalable and extensible. Developed to operate on a multiprocessor distributed architecture, the Symantec PKI Platform contains high-performance transaction engines and scalable database systems Additionally, components of Symantec PKI Platform can be distributed across multiple servers to support very high workloads and availability requirements. Designed to scale from thousands to hundreds of millions of device and user credentials, it is extensible in a way that allows organisations to take advantage of new services and solutions as they become available from service providers. Provides full certificate lifecycle management capabilities Symantec PKI Platform gives service providers end-to-end control over their PKI infrastructure, and is capable of supporting millions of end user digital certificates on a global scale. Supports open standards. Symantec leverages a highly available infrastructure that supports open standards and protocols including X.509 certificate and CRL standards and PKCSx for certificate enrolment and delivery. V1.1 4

5 Proven for large-scale deployments. Symantec PKI Platform is currently deployed in more than 20 large-scale PKI data centres worldwide, and underpins global e- commerce, large scale device ecosystems and government national ID. Symantec PKI Platform Architecture Architecture diagram redacted V1.1 5

6 3 Symantec PKI Platform (SPP) architecture xxxxx 4 Meeting DCC SMKI Service Requirements xxxxx 5 Register new RA agent (CA Manager) The CA management portal allows the administrator to appoint new RA agents as follows: CA Managers perform validation of RA agents according to the defined CP/CPS, and then use the CA management portal to enrol each RA agent and issue credentials for access to the RA agent portal. 6 Register new subscriber (RA Agent) The RA Agent portal allows RA Agents to register new service users to the subscriber portal as follows: The RA Agent performs validation of the service user according to the defined CP/CPS, then uses the RA Agent Portal to enrol the service user as an authorized subscriber, and issues credentials for access to the subscriber portal. Credentials are provided as a PKI certificate on a PIN protected USB token. 7 Request organisational certificate (Authorised Subscriber) V1.1 6

7 This portal provides the following functionality: Request issuance of individual end-entity Organisational certificates by means of uploading a PEM encoded PKCS#10 Certificate Signing Request (CSR) Download of individual end-entity Organisational certificates in PKCS#7 format. The PKCS#7 file will contain the end-entity Organisational certificate and the issuing OCA certificate. The subscriber portal allows authorized service users to request individual organizational certificates as follows: The service user authenticates to the authorised subscriber portal using the credentials provided by the RA agent at registration time. The flow from that point is as follows: i. The service user acknowledges the subscriber agreement and then submits the certificate signing request (CSR) along with the type of organisational certificate required. ii. The SMKI verifies the integrity of the request, and checks whether a certificate has already been issued for that organization. If so, then the service user is asked to acknowledge that fact iii. Once the request is submitted, the RA agent is notified. The agent signs into the RA Agent Portal to review the request, along with any other pending requests V1.1 7

8 iv. The details provided with the request include the requesting organization, user, and certificate type, as well as any other relevant details, such as whether certificates have been issued to this organization before (along with subscriber acknowledgement of the same) v. Once the RA Agent approves the request, the request is submitted to the OCA system for issuance. vi. The OCA system signs the certificate under the OCA issuing CA, publishes the certificate to the PKI Database, and then notifies both the applicant and the RA Agent that the certificate has been issued. vii. The service user then signs back into the subscriber portal to pick up the newly issued certificate. 8 Request device certificate (Authorised Subscriber) This portal provides the following functionality: Request issuance of individual end-entity Device certificates by means of uploading a PEM encoded PKCS#10 Certificate Signing Request (CSR) Presentation of individual issued end-entity Device certificates in PKCS#7 format. The PKCS#7 response will contain the end-entity Device certificate and the issuing DCA certificate V1.1 8

9 The subscriber portal allows authorized service users to request individual device certificates as follows: The service user authenticates to the authorised subscriber portal using the credentials provided by the RA agent at registration time. The flow from that point is as follows: i. The service user acknowledges the subscriber agreement and then submits the certificate signing request (CSR) for a specific device. ii. The SMKI verifies the integrity of the request and checks whether a certificate has already been issued for that organisation. iii. If the request is for the first or second certificate pair for that device, then the request is immediately submitted to the DCA system for issuance. iv. If the request is for the third or subsequent certificate pair for that device, then the request is queued for RA approval, and the RA Agent notified. At that point the RA Agent may reject or approve the enrolment, at which time the applicant will be notified that they should resubmit the request for instant approval. v. The DCA system signs the certificate under the DCA issuing CA, publishes the certificate to the PKI Database and then notifies both the applicant and the RA Agent that the certificate has been issued. V1.1 9

10 vi. The service user then signs back into the subscriber portal to pick up the newly issued certificate. 9 Register device certificate batch (Authorised Subscriber) This portal provides the following functionality: Request issuance of batches of end-entity Device certificates (max 50K per batch) by means of uploading ZIP files containing PEM encoded PKCS#10 Certificate Signing Requests (CSRs) Download of batches of issued end-entity Device certificates by means of downloading ZIP files containing PEM encoded PKCS#7 format files. Each PKCS#7 file will contain an end-entity Device certificate and the issuing DCA certificate View of current SMKI overall batch pipeline in an anonymised form View of own organisation current submitted batch pipeline processing status (older non-downloaded batch results may be present where storage permits) The subscriber portal allows authorized service users to request batches of up to 50,000 device certificates as follows: The service user authenticates to the authorised subscriber portal using the credentials provided by the RA agent at registration time. The flow from that point is as follows: V1.1 10

11 i. The service user acknowledges the subscriber agreement and then uploads a file containing a batch of up to 50,000 certificate signing requests. ii. The SMKI verifies the integrity of the batch, and starts processing the requests one by one. iii. For each request, if the request is for the first or second certificate pair for that device, then the request is immediately submitted to the DCA system for issuance. iv. If the request is for the third or subsequent certificate pair for that device, then the request is queued for RA and the request is added to a list of requests requiring approval. v. The DCA system signs each certificate under the DCA issuing CA, publishes the certificate to the PKI Database and adds the new certificate to the output batch. vi. Once the whole batch has been processed, the RA is notified that the batch is complete, along with a summary of the certificate issued, rejected or queued for approval. The applicant is also notified that the batch has completed processing. vii. The service user then signs back into the subscriber portal to pick up the newly issued certificate batch, along with a summary. viii. If there were any requests which were rejected because of the detection of multiple duplicates, the RA Agent signs into the RA Agent Portal to review and approve/reject each request, after which the service user is notified to allow them to resubmit those requests for instant approval. 10 Request device certificate (Authorised System) This provides the following functionality: Request issuance of individual end-entity Device certificates by means of uploading a PEM encoded PKCS#10 Certificate Signing Request (CSR) within the XML web services message structure Receive individual end-entity Device certificates by means of a PEM encoded PKCS#7 message contained within the XML web services response. The PKCS#7 message will contain the end-entity Device certificate and the issuing DCA certificate The system to system interface allows authorized systems to request individual device certificates as follows: V1.1 11

12 Start Authorised System Authenticates to Portal System submits CSR No SMKI verifies CSR Verifies OK? Reject Enrolment Yes Notify System owner to resubmit Queue for RA approval and notify RA Yes Second Duplicate? No Check for duplicate machine ID Stop Notify System owner No Approved? Yes Stop Request submitted to CA CA issues certificate Stop Certificate returned to Authorised System SMKI publishes certificate(s) to PKID The system authenticates to the system to system interface using the credentials provided by the RA agent at registration time. The flow from that point is as follows: i. The SMKI verifies the integrity of the request and checks whether a certificate has already been issued for that organisation. ii. If the request is for the first or second certificate pair for that device, then the request is immediately submitted to the DCA system for issuance. iii. If the request is for the third or subsequent certificate pair for that device, then the request rejected is queued for RA action, and the RA Agent notified. At that point the RA Agent may reject or approve the enrolment, at which time the System Owner will be notified that they should resubmit the request for instant approval. iv. The DCA system signs the certificate under the DCA issuing CA, publishes the certificate to the PKI Database and returns the certificate to the authorised system. 11 Revoke Organisational Certificate (RA Agent) The RA Agent portal allows RA Agents to revoke organisational certificates as follows: V1.1 12

13 RA agents perform validation of revocation requests according to the defined CP/CPS, then use the RA Agent portal to locate and revoke the required certificate. The revocation request is immediately passed to the OCA system, which marks the certificate as revoked within the CA database. The certificate will be included in all subsequent CRLs issued by the OCA and published to the PKI database. 12 Other RA portal functionality (RA Agent) The RA portal will also give the following functionality to DCC RA people: Revoke Authorised Subscribers View of current SMKI overall batch pipeline 13 Publishing Interface (to DSP PKI database) This will use an interface standard to be agreed with the DSP such as a Web Services interface on the DSP platform. Publishing data to the DSP PKI database within SLAs is reliant upon the database being able accept the published data at the rate at which it is generated. This provides the functionality to publish the following dynamic information: o o o o End Entity Public Key Certificates Issuing DCA Public Key Certificates Authenticity info for issuing DCAs such as hash of DER encoded x509 structure CRLs and ARLs for Organisational PKI The following static information also needs to be published to the PKI Database but the infrequent nature of changes to such information means that this can be transferred by an out of band solution e.g. o o o Certificate Policy and PKI Disclosure Statements Supporting policy docs and agreements Root Public Key Certificates V1.1 13

14 o o Issuing OCA Public Key Certificates Authenticity info for issuing OCAs such as hash of DER encoded x509 structure 14 BT Hosting and Operations BT will deploy the operational SMKI platform in two of its secure ISO27001 accredited data centres. There will also be a Disaster Recovery platform, maintained in a warm stand-by state located in a separate secure ISO27001 accredited data centre. Both of these platforms will be built and operated in a highly resilient configuration. A physically separate test platform will be deployed in one of the locations to facilitate the System Integration Testing and at the end of the testing phase will become the enduring test platform. The test platform is a fully featured, nonresilient model but much lower capacity for the DCCs end users as well as the DCC to test their services with the PKI and to be able to test the PKI services work with end devices. Certificates from the test system will NOT interwork with the main systems and are only to be used for test purposes and will not offer the same level of assurance, or availability. The data centres deploy strict multi-tiered access controls with anti-pass back checks in place. All of the platforms will be managed and operated using BT s secure management systems by xxxx BT teams with many years of experience with Symantec PKI technology. Physical and logical access to the platforms will be restricted to a limited set of individuals with clear separation of roles. The off-line root CA operations will be carried out in BTs Key Ceremony facility under strict scripted and witnessed ceremony conditions with the option of a video recording being made if the CP/CPS dictates as such. Between operations, the Hardware Security Modules protecting the root private keys will be stored in a highly secured storage safe requiring xxxx personnel to be present in order to physically access the HSMs and further multiple individuals required to activate the private key material. The individuals required for both physical access and activation can be a combination of both BT and DCC personnel. V1.1 14

15 BT has an excellent track record hosting and operating tscheme accredited PKI platforms for multiple customers using well proven processes and procedures. The following have been taken through accreditation: the BT Assure PKI service, the BT Managed Secure Messaging service, and; xxxx. Part D SMKI Implementation and Project Management 1 Implementation/Project Approach The SMKI Service needs to operate at a scale that is rare in the market and the scale and complexity of the SMKI project means that the overall timescales are challenging. This represents a significant risk to the overall DCC programme. BT/Symantec has a proven track record of delivering PKI services that operate at this scale to mitigate this risk. In addition BT/Symantec has an existing UK PKI service operation, manned by existing security cleared personnel and supported by robust service management processes, and experience of taking several services through tscheme approval, all of which helps to minimise the risk to DCC. We understand the importance of strong collaborative Programme/Project management and sound governance to deliver on time and against an agreed plan. We also recognise that it is essential that all stakeholders parties buy-in to the Programme/Project delivery process and that the plan defines clearly the responsibilities of each party and the resource commitments that have to be made in support of this. Given this, we are in no doubt that we can develop and agree a project plan for the SMKI service that is aligned with overall DCC delivery programme and supports the required SMKI go live date of April 2015 Part E Staff Capability and Capacity 1 BT/Symantec will provide the SMKI project, the joint strengths and capabilities of two world class implementation and support organisations. At the front line, the BT Operational team are managing the day to day operations and implementation, and the team structure to support this is detailed below. Complementing BT are Symantec s 24x7 Support Organisation with extensive operations, implementation and development expertise. This depth and capability will significantly enhance the implementation and operational phases. 2 There are three teams, structured under common Operations line management that would assume primary responsibility for accepting the contract into service (AIS) and support in-life operation: V1.1 15

16 i. Service Level Management (SLM) and Information Security Management (ISM) Assumes overall responsibility for development and in-life compliance for all service life-cycle stages (strategy, design, transition, operation and service improvement). They provide the first point of customer contact in matters notwithstanding BAU issues (see Service Desk below). The team also produce, maintain and enforce Information Security Policy and lead all activities that ensure associated accreditation (ISO27001and tscheme) is maintained. The team currently provide inlife support for several managed Trust Services platforms including three managed PKI services. The team is accredited to ITIL Service Management foundation standard as a minimum with managers accredited as ITIL Service Manager. ii. Service Desk For BAU this team provide first line customer liaison in accord with agreed Service Level Agreements (SLA). The Desk is organised under a Service Desk manager into 3 key disciplines a) Customer Contact b) Billing and Ordering and c) Key cryptology. Their functional focus is primarily event management They are effectively the bridge between technical support teams and the customer. They currently provide the Service Desk and function for several large Trust Services platforms and the cryptology function for three PKI services. The Service Desk manager is qualified and certified as a Symantec Cryptographic Key Manager with several years experience. For key ceremonies, the Service Desk manager will recruit xxxx personnel from within and without his direct team to resource mandated role segregation. iii. Application Support Group (ASG) The ASG team are the technical bridge that manages all technical issues received from the customer via Service Desk or via service monitoring and alerting. Their primary role is to inaugurate and support the application tier. However they are custodians of the entire technical service and therefore liaise with mid-tier (e.g. database administration, network administration, hardware support, design and development, vendor) and environmental teams (e.g. data centre, media-management) to introduce new services and resolve issues with in-life. They provide 24*7 cover for service affecting issues and system implementations that require deployment outside normal business hours. The ASG team currently manage a portfolio of several large Trust Services platforms including two large PKI services. Engineers are trained by Symantec in PKI application management and are skilled in all flavours of server administration through Unix/Linux and Windows. 3 Other operational teams are engaged to provide support for non-business hours and are involved with the hosting and support of business continuity (BC) capabilities and the Service Desk function. Part F Organisational Ability and Supply Chain 1 BT/Symantec recognises that this project is a complex large scale programme with high profile stakeholder perception in the UK. We have reviewed the Programme and DCC SMKI requirements in detail. We believe that with our mutual capabilities V1.1 16

17 we are perfectly positioned to meet the requirements to budget, and to high standards to deliver a live operational system within the desired timeframes. BT/Symantec senior executives are committed to the delivery of the SMKI service and to ensure that DCC deliver a successful Programme for DECC. 2 BT/ Symantec have been delivering PKI services to clients for over 15 years. BT have the largest enterprise class PKI services provision in the UK and deliver complex National Government Programmes such as xxxx. Symantec PKI platforms delivers over xxxx certificates globally annually with an incremental annual growth rate of over xxxx. Symantec commit significant R&D to the development of PKI services and technologies. 3 BT/ Symantec believe there are key requirements from this project that our unique synergies can enable DCC to deliver within timescales and with reduced risk and management burden: DCC have a high volume roll-out within short timescales We offer a robust, secure operational capability. We offer a managed SMKI service with robust business continuity and risk management through high availability architecture, backed by binding Service Level Agreements, independently audited operations and 24X7 technical support. We offer a scalable platform proven to deliver large scale volumes with within the desired performance metrics; DCC need an experienced provider who can deliver to time, budget and within the structure of the DCC Programme Plan; We can evidence and have the practical experience of large scale roll-outs and working in multiple stakeholder environments such as xxxx. We are delivering and supporting some of the largest PKI projects globally We have tangible experience in working with stakeholders in Government and Utilities markets, and working specifically on European Smart Metering Projects DCC need an established operational service provision to reduce risk and costs; We offer delivery through an established operational service with tscheme accreditation; We offer xxxx resources and multiple levels of support capabilities from technical expertise, to PKI expertise to Service management and tscheme; V1.1 17

18 DCC need a committed service provider who knows and is investing in the market; We have substantial knowledge of, and significant investment in, the future direction of PKI technology BT are working to evolve tscheme and Symantec have a significant range of investment in PKI technology and IPR globally; We are committed to the UK Public sector and PKI market We have a long term presence in both markets. We offer a very competitive commercial model; 4 Running a managed PKI service is the sole focus of the BT operational unit. Both BT/Symantec operations and technical personnel adhere to the highest IT/InfoSec standards and Best Practices. BT data centres are externally audited every year to ensure the services meet certifications and accredited policy statements. Part G The Recovery Process The scenarios which must be planned for as part of the overall DCC service design are as follows: 1 Device key compromise, whereby a smart meter device key store has been compromised, corrupted or rendered unusable. This may occur for an individual device, or a batch of devices for example a production run of metering equipment with a known flaw. 2 Organisational key compromise, whereby an organizational key has been compromised, lost, corrupted or rendered unusable. This scenario may vary in severity, depending on the role assigned by the certificate(s) corresponding to the private key. 3 Certificate Authority key compromise, whereby a Certificate Authority key has been compromised, lost, corrupted or rendered unusable. This is a very unlikely scenario, given the closed and highly controlled environment in which the CA key material is managed. Example scenarios include, in increasing order of severity, compromise of the Issuing CA, Root CA, Apex Trust Anchor CA, or Contingency Key. Role of the SMKI A primary role of the SMKI is to manage and secure all Certificate Authority key material. BT and Symantec have a long and unbroken history of securing highly sensitive private key material for government and e-commerce, including various National ID systems around the world, and the VeriSign Root Certificate Authorities which underpin global e-commerce. V1.1 18

19 In the case of organizational key compromise, certificates are revoked and reissued according to the CP/CPS, supported by the RA Agent and Authorised Subscriber portals within the SMKI. In the case of device key compromise, the key regeneration and certificate replacement is a function of the subscriber or the device management systems. The SMKI supports this process through re-enrolment of the device certificates, which may trigger the 2nd duplicate device check and subsequent RA agent review, as per the SMKI workflows in the solution overview section. In the case of CA key compromise, any compromised issuing CAs will be revoked if applicable, and any certificates issued under those CAs will be revoked (if organizational certificates) and reissued under a new issuing CA. Device certificates will be provisioned using the existing device management systems. Organisational certificates may be re-enrolled via the authorized subscriber portal. In the case of Root CA key compromise, a new Root CA certificate is generated within the SMKI via a Root CA key ceremony. The distribution of the new Root CA key is a function of the DCC Trust Anchor Management System (TAMS), using the signing certificate issued by the SMKI. In the case of compromise of the Apex Trusted Root (assumed to be the OCA root), the TAMS will need to load the apex contingency private key together with the decryption key to allow TAMP end points to unwrap the public key embedded within the OCA root certificate. Protection of the contingency key may form part of the SMKI key management function, with the key stored on an offline HSM for which multiple PIN Entry Device (PED) tokens are required for key export. Once the key is exported, a new key and OCA root is generated. Key protection for the contingency recovery key It is recommended that the contingency recovery key is generated and stored on a dedicated portable hardware security module, such as Safenet Luna CA4 or G5 module, as a non-exportable private key. This will give the same (or greater) level of key protection as the issuing and root CA keys. During a recovery situation, the Trust Anchor Management System would communicate with the HSM using a standard PKCS11 interface to access the private key in order to perform the required TAMP operations. The end to end process for generating and deploying the recovery key would be as follows. Key Ceremony: The Key Manager initialises the HSM, and defines the share policy: for example, 5 hardware keys to be registered, of which 3 are required to start up the HSM. The key manager then connects the PIN entry device (PED) to the HSM, and starts the initialisation and key generation process. During this process, the PED will prompt for each shareholder in turn to insert their hardware key into the PED USB V1.1 19

20 slot. Once all hardware keys have been registered, the contingency recovery key pair is generated within the HSM. The public key is exported, and the private key remains within the HSM. There is no way to export the private key from the HSM. The HSM is then shut down, and placed in the safe in the key ceremony room. The shareholders retain possession of their hardware share keys. Recovery: If the worst case scenario happens, and the contingency recovery key is required, the HSM is retrieved from the safe, and transported to the trust anchor management system, where it is connected to the host ready for use. The requisite number of shareholders are assembled, along with their hardware keys. The PED is connected to the HSM, and the TAMP system started. The PED will prompt each shareholder to insert their hardware key in turn, until the requisite number of keys has been entered (for example 3 of the 5 registered keys). Once the required number of keys have been inserted, the HSM will start up, and the contingency key will be available to the TAMP system software. Options: One option is to clone the HSM during the initial key ceremony, using the secure cloning mechanism provided by the HSM firmware. In this case, one HSM could be transported to the TAMP system facility (but not activated), and the clone HSM kept in the key ceremony room safe as backup. In this case, the HSM would not need to be transported to the TAMP facility for recovery - although the shareholders would still need to be present to start the HSM. Part H RA Management and RA Agents 1 We have included within our Solution Overview (part C) a number of process workflows that show how individual certificate requests will be handled and the role that the DCC RA plays in these processes. 2 BT/Symantec will work with DCC during the design phase of the SMKI implementation to develop the specific tools and define and document the processes and procedures that authorised subscribers and DCC RA personnel will need to follow to submit and approve CSRs prior to their transmission to either the Device or Organisation Certificate Authorities to support these workflows. 3 BT/Symantec will, once the processes are documented and the tools developed, produce a set of training materials and carry out a number of train the trainer sessions for DCC at BT or DCC offices so that these trainers can train authorised subscribers and RA agents before the start of User Integration Testing. These training materials will be maintained throughout the lifetime of the contract and updated to reflect any changes to the tools, processes and procedures that are V1.1 20

21 required once the service is operational, so that they can be used to train new personnel or provide any refresher training that is needed over the lifetime of the project. 4 In addition, BT/Symantec will work with DCC to define and document a robust process for identifying and validating individual subscribers and RA agents that is commensurate with Device and Organisation Certificate Policies (CPs), associate Certificate Practice Statements (CPSs) and HMG Level 3 as defined in GPG43, during the design phase. These processes will draw upon our unparalleled experience of delivering PKI projects for financial, government and other institutions globally as well as other projects for UK government. Part I Certificate Issuance Performance Metrics 1 BT will produce weekly and monthly management reports for DCC as stated in the requirements, which detail performance of the SMKI against the metrics for both the issuance of certificates for Device and Organisation Certificate Authorities as well as all the other service level metrics. The content, structure and frequency of these reports will be agreed with DCC during the design phase, but will include as a minimum information on the number of certificates requested, issued and where appropriate revoked by each organisation together with details of the time taken to respond to each certificate issuance or revocation request following approval. The report would also contain information, again split by organisation, of the number of batches submitted, the size of these batches and when these were submitted, approved and the certificates returned. 2 In addition, the RA portals for both the Device and Organisation Certificate Authorities will enable the RA Manager and individual RA Agents to view the certificate requests by organisation and view the number of certificates that have been issued, those certificate requests that have been rejected and any certificate requests that are pending waiting approval by the RA. It will also allow the RA Manager and RA Agents to view when individual certificates and batch requests were submitted, approved and actioned. 3 Every event in the certificate lifecycle is fully audited within the PKI backend system, including certificate request, approval, issuance and revocation. The time stamped audit trail includes full certificate details along with information of the actors involved. The audit trail is stored within the Symantec PKI Platform database indefinitely, and available for reporting via the administration interface or directly from the database for custom reports. Part J tscheme Compliance 1 BT has been an active member of tscheme since its inception in BT has the practical experience of taking three major services through the tscheme approval process namely: V1.1 21

22 the BT Assure PKI service, the BT Managed Secure Messaging service, and; xxxx, which BT manages on behalf of the xxxx, through the tscheme approval process. 3 BT s PKI service operations are already ISO/IEC27001:2005 accredited and we propose to extend the scope of this ISMS to include the OCA and DCA service operations and extend this accreditation, which will be transitioned to ISO/IEC27001:2013 in the coming 12 months, to include those elements SMKI service that we would deliver to DCC to enable tscheme approval to be achieved. 4 tscheme will not approve services before they are operational. We would therefore plan to obtain Scheme Registered Applicant status for 1 September Registered Applicant status sets out the scope of the service approval and an agreed timeline for completing the tscheme assessment, and would ensure that full tscheme approval can be obtained within the first quarter of live operation. 5 To support DCC in delivering tscheme accreditation, BT will produce the Specification of Service Subject to Assessment (S3A), engage the tschemerecognised assessor and manage the accreditation process. However, as the tscheme accreditation will cover the full scope of the SMKI and not just those elements provided by BT/Symantec accreditation, DCC input will be required to complete the S3A and to confirm how the requirements of the tscheme Base Approval Profile, which primarily relates to the overall governance of the service, are best evidenced. DCC will also need to ensure that the PMA and its Registration Authority service operation are in scope of its own BTISO/IEC27001:2005(2013) accreditation and provide support for the annual audits of these elements of the SMKI service by the tscheme-recognised assessor appointed by BT. Our knowledge and experience in this area will reduce the overall cost, effort, risk and time associated with the delivery of tscheme accreditation for DCC. Part K 1 General Testing Within the auspices of the overall Project Plan, the BT Project Manager and Test Manager will be responsible for the Testing work packages. The Testing Manager will generate initial draft Test Strategy & Test Data Strategy for consultation with the DCC and other stakeholders during the Design Phase. This initial draft will be based on the real experiences of developing similar plans V1.1 22

23 across a range of other Government and Commercial clients implementations. There is a standard system test plan for the base PKI platform, which is supplemented with test cases for any additional components and workflows specific to a particular implementation. This test plan is drafted during the preimplementation phase, and would be presented to, and agreed with DCC prior to this stage. 2 The Test Manager with the BT PKI service experts will work with DCC and stakeholders to define, document and agree the final testing strategy, associated risks, dependencies and timing within the overall Project Plan. The deliverables at the end of this activity will be the Test Strategy, the Test Data Strategy and detailed Test Plan with its interdependencies. These deliverables will enable the DCC to more accurately understand the various scope, objectives, deliverables, risks and efforts involved in the PIT, SIT and UIT stages. 3 Key activities will include: Agreeing communication protocols Defining SMKI platform s non-functional tests & acceptance criteria - System documentation, system performance and security model validation Defining the functional & interface tests along with acceptance criteria - Systems tests, data level tests, user interface tests 4 The SMKI platform will undergo a process of software implementation and configuration, followed by activation with CA keys for integration testing. This system activation is referred to as bootstrapping, from which point all CA activity is controlled and audited as per CP/CPS requirements. System testing of the platform consists of two major phases: pre-bootstrap component testing, and post-bootstrap end to end testing. Once pre and post bootstrap tests are completed, witnessed and signed off by DCC stakeholders, the SMKI moves into the user integration testing phase. Symantec and BT act in a supporting role during this phase, providing input into test activities where necessary and addressing any issues that arise. 5 Testing Assurance BT/Symantec will design a test plan which covers all requirements documented within the DCC SOR, together with any requirements arising from subsequent clarifications and discussions between BT and DCC. Each test case will reference one or more specific requirements. The test plan is presented to DCC for approval and adjusted as necessary before signoff. The test plan includes the process for signing off each test case, including the DCC authorised witnesses, witness schedule and activities to be witnessed. Test results are entered for each test case, together with any relevant output data. V1.1 23

24 In order to streamline the test witnessing process, the test plan will be executed twice. The plan will first be executed by BT internally during the pre-bootstrap build phase. Once all tests are complete, the system is reinitialised and all test data removed, and the test plan is then executed a second time, with full witnessing by DCC stakeholders. Only when all tests are complete and witnessed will the system be signed over for user integration testing. 6 Pre-Integration testing The SMKI platform will undergo a process of software implementation and configuration, followed by activation with live issuing CA keys. The activation of live CA keys is referred to as bootstrapping, from which point all CA activity is controlled and audited as per CP/CPS requirements. System testing of the platform consists of two major phases: pre-bootstrap component testing, and post-bootstrap end to end testing. There is a standard CLP system test plan for the base platform, which is supplemented with test cases for any additional components and workflows specific to a particular implementation. This test plan is drafted during the pre-implementation phase, and agreed to by DCC prior to the professional services engagement. The System test plan is executed twice. The first execution (pre bootstrap testing) occurs during initial setup to ensure that all components are operating correctly as they are installed and configured with test CA keys. Any issues arising during this phase which cannot be fixed immediately are raised with support and allocated a case number. Once the software is operating correctly and all tests completed successfully, the system is reinitialized and cleaned of any test data before being activated with user integration live CA keys. The test plan is then executed a second time (post bootstrap testing), with each test case being witnessed by DCC. Once all post bootstrap tests have been completed successfully, and to the satisfaction of DCC, the system as a whole is signed off as fully operational, and may be opened for Integration Testing. 7 Integration testing BT and Symantec will work with DCC to build a service user facing test plan. This plan may be based on the workflow test cases included in the system test plan, and will include end to end testing of subscriber services, including registration, portal access, individual certificate request, batch certificate request and certificate pickup. 8 Testing Environments BT/Symantec will provide three physically separate PKI platforms to support the SMKI implementation. V1.1 24

25 The first is the development/reference PKI platform that BT/Symantec will use for its own internal system/pre-integration testing. This platform will be retained for the duration of the contract and will be used to test new release and enhancements to the service, should these be required, before these are deployed onto the either the DCC test or production environments. The second is the DCC test environment, which will be provisioned for start of Pre-Integration Testing and which will be used to support DCC System Integration and User Integration testing. This platform will again by retained for the duration of the contract and will, following the completion of system and user integration testing, provide the enduring test environment that is required for business as usual (BAU) testing and to facilitate new entrant service user testing. The third is the DCC production environment, which will be provisioned for the start User Integration testing on 1 April 2015 and will be replicated in a second secure site to ensure business continuity. The DCC test environment will be located in the same secure site as one of the two production platforms and will be supported by the same operational team, but will be exist on physically separate hardware and share no common components. The test and production systems will make use of a shared data centre back-up solution 9 Testing Defect Management All incidents and defects reported to the BT Service Desk will be ticketed and the priority level agreed with DCC and regular updates provided in line with the agreed service levels until the incident is resolved or the defect corrected. Where this requires a new release of any software component or a configuration change, BT will first deploy this onto its development/reference environment and execute a test plan that is commensurate with the complexity and scale of change, and its likely impact in event of failure. BT/Symantec will share the results of this testing and, if appropriate, the rollback plans for backing out the change in the event of problem, and obtain DCC agreement before rolling out the change onto the DCC test environment. This will enable DCC to perform any additional testing that might be required to ensure that the change has no adverse impact on the wider DCC eco-system. BT/Symantec will advise DCC on the scope of testing that is needed for any change or new release and will recommend which subset of tests from the originally agreed user facing test plan should be performed before the change is rolled out onto the production environment. V1.1 25

26 Once DCC has completed and signed-off on these tests, BT will implement the change on the DCC production environment in a manner that minimises the impact on the overall SMKI service and at a time agreed with DCC. Any changes to software components will be merged back in to the version managed product code repository. The details of the ticket will be recorded against the software component changed in the repository. All changes will be supported by an appropriate documentation pack, which will include release notes detailing fixed tickets, completed test plans and, where appropriate, updates to any process and support documentation, User Guides and training materials. Part L Service Management 1 BT operates an existing large scale operational service and believes that the complexity of the SMKI programme demands absolute adherence, by all service components providers, to a common Service Management protocol. 2 The ITIL framework is an ideal basis upon which to design and implement an integrated service model. BT underpins all new service provision with the ITIL best practice. Success in terms of SMKI delivery schedule and in-life operations will be determined by a coherent and binding strategy by all DCC providers across the entire service life-cycle. 3 The BT Service Manager would be responsible for working with the DCC Service Manager s during live operations to deliver the service metrics outlined in B8/SoR Appendix C for the DCC and its stakeholders. 4 Service Management - risks and mitigation The key risks to effective Service Management for the SMKI programme need to be addressed at Service Strategy stage. It would arise from a fragmented approach to service provision by SMIP service providers with the big picture out of focus or misaligned to the desired SMIP business outcomes. The consequences of such an approach include; Service providers adopting a silo mentality towards service delivery. Functional IT delivery askew with Service delivery Communication channels are evoked in reaction to problems only. Service analytics are incoherent, incomplete and as a result incredulous. V1.1 26

27 To mitigate this risk the DSP, the CSP and SMKI suppliers must collaborate with Smart DCC in design and development of the service. It is imperative that this commence at the start of the PIT Phase. BT would recommend that DCC appoint Service Champions from each of the providers who would consult and cooperate as a forum. At the Service Strategy stage of the service life-cycle the forum would liaise with service user representatives to agree and define the service. This definition would be the basis of the Service Level Agreement (SLA) between Smart DCC and the suppliers. The forum would also determine and obtain business/financial approval for service provision. Following Service definition, the Service Champion forum would develop and publish clear and unambiguous Service stratagem to their respective Service Design teams. These teams will develop the Operational Level Agreements (OLA) that underpin and cost in with the SLA. Ineffectual or non-existent management during Service Transition phase is the primary cause of system and consequential business failure. The Service Champion forum would provide the core of the Change Approval Board (CAB) and ensure scope, risk and business benefits for all changes were aligned. The Service Champion forum would retain its role in maintaining service awareness throughout the Service Operations. Quality information shared between service suppliers is the critical life-blood of the SMIP service. A common service data portal is important but the establishment of business relationships should be given strategic priority as well. Regular operations forums are one means to this end. As key drivers for Service Improvement initiatives, the Service Champion forum should determine the data that provides the best measure of service success and weakness. BT/Symantec recognises that this project is a complex large scale programme with high profile. V1.1 27