Incident Response

1. Purpose and Scope

This plan establishes the procedures, roles, and responsibilities for detecting, responding to, containing, and recovering from security incidents that may affect the confidentiality, integrity, or availability of the ddsign E-CSP's services.

This plan applies to all security incidents affecting:

• The ddsign Certification Authority, including the Issuing CA and all associated key material.
• The Registration Authority systems and identity verification processes.
• Subscriber data, including personal data, transactional records, and historical usage records.
• The ddsign platform infrastructure (backend, frontend, database, HSM, network).
• Certificate status services (CRL distribution, OCSP responder).
• Supporting systems (Sentry monitoring, CRM, email infrastructure).

Regulatory Basis

• Kenya Information and Communications Act (KICA): Requires E-CSPs to notify the Communications Authority within 24 hours of confirmed security incidents.
• Kenya Data Protection Act, 2019: Requires notification of the Data Protection Commissioner within 72 hours of a personal data breach.
• ETSI EN 319 401: Requires Trust Service Providers to maintain incident management procedures.
• CPS Section 5.7: Mandates compromise and disaster recovery procedures for the ddsign CA.

2. Incident Response Team

Escalation Path

1. Alert raised via Sentry (sentry.centricltd.co.ke), Subscriber report (support@ddsign.ae via CRM), or internal observation.
2. Technical Lead performs initial triage and assigns severity.
3. Medium and above: Incident Commander notified immediately.
4. Critical: all IRT members mobilised. Incident Commander assumes control.
5. External notifications issued per timelines in Section 7.

3. Incident Classification

4. Incident Response Procedures

4.1 Detection and Reporting

• Sentry monitoring: Self-hosted at sentry.centricltd.co.ke. Monitors application errors, exceptions, and performance across all ddsign components. Alerts via dashboard and email.
• Subscriber reports: Via support@ddsign.ae, tracked in the sand-social.com CRM.
• Internal observation: Any staff member reports suspicious activity to the Technical Lead.
• External notification: The Communications Authority, KE-RCA, or security researchers may notify the E-CSP.

4.2 Assessment and Classification

1. Confirm whether the report is a genuine incident or false positive.
2. Assign severity (S1-S4) per Section 3.
3. Notify Incident Commander if Medium or above.
4. Mobilise appropriate IRT members.
5. Open formal incident record.

4.3 Containment

• Network isolation: Denis Kipkemboi modifies firewall rules or disables interfaces.
• Service suspension: Technical Lead suspends certificate issuance while maintaining read-only status services.
• Account lockout: Levy Ochieng' disables compromised accounts or revokes privileges.
• HSM isolation: Joseph Kang'ethe disconnects the HSM from the application layer (requires Technical Lead confirmation).
• Key ceremony halt: All pending key ceremonies suspended.

4.4 Eradication and Recovery

1. Root cause identified through log analysis and forensic investigation.
2. Vulnerability or attack vector eliminated.
3. Systems restored from verified clean backups.
4. CRL/OCSP verified as operational and accurate.
5. Technical Lead confirms readiness for normal operations.
6. Incident Commander authorises return to normal operations.

4.5 Post-Incident Review

Within five (5) business days of closure:

1. Post-incident review meeting with all involved IRT members.
2. Root cause analysis (RCA) report produced.
3. Corrective actions identified, assigned, and tracked.
4. This plan updated if a gap was revealed.
5. RCA report filed and made available to the auditor.

5. Compromise Control

5.1 CA Private Key Compromise

The most severe scenario. Procedure:

1. Isolate: Joseph Kang'ethe immediately disconnects the HSM from all application connections.
2. Dual authorisation: Arnold Wamae and Margret Mumbi both authorise revocation of the Issuing CA certificate. Neither may authorise alone.
3. Revoke and publish: Joseph Kang'ethe executes revocation and publishes an emergency CRL within one (1) hour.
4. Notify KE-RCA: Arnold Wamae notifies the Kenya Root CA (ICTA) to revoke the cross-signed certificate.
5. Notify CA of Kenya: Margret Mumbi notifies the Communications Authority within 24 hours.
6. Subscriber notification: All Subscribers notified via email, SMS, and in-app that their certificates are no longer valid.
7. Public notice: Website banner posted on ddsign.app.
8. Media: Margret Mumbi issues a prepared holding statement if enquiries are received.
9. Recovery: New Issuing CA key generated in a witnessed key ceremony, cross-signed by KE-RCA, new Subscriber certificates issued.

5.2 Subscriber Key Compromise

1. RA verifies identity of the person requesting revocation.
2. Joseph Kang'ethe revokes the affected certificate.
3. Updated CRL published within one (1) hour. OCSP reflects revocation in real-time.
4. Subscriber notified via email and in-app.
5. Subscriber may apply for a new certificate.

5.3 RA System Compromise

1. Certificate issuance immediately suspended.
2. All identity records since last known-clean state flagged for re-verification.
3. Certificates issued on fraudulent data revoked.
4. RA system rebuilt from verified clean state.

5.4 Subscriber Data Breach

1. Levy Ochieng' preserves all relevant logs and evidence.
2. Scope assessed: data categories, Subscribers impacted, likelihood of harm.
3. Data Protection Commissioner notified within 72 hours if risk to Subscriber rights.
4. Affected Subscribers notified without undue delay.
5. All breach communications tracked in CRM (sand-social.com).

6. Revocation Conditions and Procedures

6.1 Conditions Triggering Revocation

6.2 Execution

1. Authorised person issues revocation instruction with serial number(s) and reason code.
2. Joseph Kang'ethe executes revocation in the CA system.
3. Updated CRL published within one (1) hour.
4. OCSP reflects new status in real-time.
5. Subscriber notified via email and in-app, including reason.

7. Notification Parties and Procedures

8. Service Disruption Procedures

8.1 Planned Disruptions

1. Maintenance window approved at least one (1) week in advance.
2. Subscribers notified at least 72 hours before via email, in-app, and website banner.
3. CRL/OCSP remain available where possible; CRL refreshed before window opens.
4. Rollback plan prepared.
5. All-clear notification sent upon completion.

8.2 Unplanned Disruptions

1. Sentry raises alert via dashboard and email.
2. Technical Lead assesses scope and assigns severity.
3. If issuance affected: suspended; existing certs remain valid, status services prioritised.
4. If CRL/OCSP affected: last valid CRL cached; status service restoration is highest priority.
5. Subscribers notified within one (1) hour. Updates every two (2) hours until resolved.
6. Post-disruption review per Section 4.5.

8.3 Degraded Mode

If partial restoration is possible, the E-CSP may operate in degraded mode: certificate status services (CRL/OCSP) available, issuance suspended. Communicated via website banner and in-app notification. Incident Commander authorises return to full operations.

9. Audit Trail Protection and Analysis

9.1 Log Sources

• Sentry: Application errors, exceptions, performance (sentry.centricltd.co.ke).
• Application logs: Backend/frontend access, certificate lifecycle, authentication.
• Database audit logs: Query logs, change data capture.
• HSM audit logs: Key usage events, tamper alerts.
• Network logs: Firewall, IDS/IPS, VPN access.
• System logs: OS authentication, privilege escalation, file integrity.
• CRM logs: Subscriber correspondence (sand-social.com).

9.2 Integrity and Tamper Protection

• Logs written to append-only storage.
• Shipped to separate, access-restricted storage within 15 minutes.
• Access restricted to Systems/Audit Lead and Technical Lead; access is logged.
• Checksums computed at collection for forensic integrity verification.

9.3 Forensic Preservation

For High (S2) and Critical (S1) incidents:

1. Forensic snapshot of all relevant logs taken immediately.
2. System memory and disk images captured where feasible.
3. Evidence labelled with incident ID, timestamp, source, and collector.
4. Chain-of-custody log maintained.
5. Evidence retained for minimum seven (7) years.

10. Media and Public Relations

10.1 Designated Spokesperson

Margret Mumbi (MD, Innovation) is the sole authorised spokesperson. No other IRT member or Centric employee may make public statements, respond to media, or post on social media about an incident.

10.2 Procedure

1. All media enquiries directed to Margret Mumbi.
2. Responses use pre-approved holding statement templates or are drafted by Technical Lead and approved by Commander.
3. Statements are factual and concise; no speculation on root cause.
4. No internal details (logs, vulnerability specifics) disclosed.
5. Social media monitored; only Commander may authorise posts.

10.3 No-Comment Policy

All staff who are not the designated spokesperson shall respond to media with: "Please direct your enquiry to our management team." Staff shall not confirm, deny, or speculate on personal social media.

11. Testing and Training Programme

11.1 Training Requirements

• All IRT members complete incident response training within 30 days of appointment and annually thereafter.
• Familiarity with this plan, escalation path, role responsibilities, and communication procedures.
• Understanding of severity classification and response timelines.
• Ability to access and interpret Sentry alerts, audit logs, and the incident register.

11.2 Tabletop Exercises

• Frequency: At least once per year, or after significant plan/team/infrastructure changes.
• Scenarios: Each exercise covers a different scenario. Over a three-year cycle, all major types (CA compromise, data breach, outage, RA intrusion) shall be exercised.
• Documentation: Date, participants, scenario, actions taken, lessons learned, and corrective actions.

11.3 Exercise Record

12. Cross-References