OpenCRVS
v1.4
v1.4
  • 👋Welcome!
  • CRVS Systems
    • Understanding CRVS
    • Effective digital CRVS systems
    • OpenCRVS within a government systems architecture
    • OpenCRVS Value Proposition
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • Users
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 6. Issue certificate
      • 7. Search for a record
      • 8. View record
      • 9. Correct record
      • 10. Verify record
      • 11. Archive record
      • 12. Vital statistics export
    • Support functions
      • 13. Login
      • 14. Audit
      • 15. Deduplication
      • 16. Performance management
      • 17. Payment
      • 18. Learning
      • 19. User support
      • 20. User onboarding
    • Admin functions
      • 21. User management
      • 22. Comms management
      • 23. Content management
      • 24. Config management
    • Data functions
      • 25. Legacy data import
      • 26. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • Application settings
      • User / role mapping
      • Declaration forms
      • Certificate templates
    • Business process flows in Farajaland
  • Setup
    • 1. Planning an OpenCRVS Implementation
    • 2. Establish project and team
    • 3. Gather requirements
      • 3.1 Mapping business processes
      • 3.2 Mapping offices and user types
      • 3.3 Define your application settings
      • 3.4 Designing event declaration forms
      • 3.5 Designing a certificate template
    • 4. Installation
      • 4.1 Set-up a local development environment
        • 4.1.1 Install the required dependencies
        • 4.1.2 Install OpenCRVS locally
        • 4.1.3 Starting and stopping OpenCRVS
        • 4.1.4 Log in to OpenCRVS locally
        • 4.1.5 Tooling
          • 4.1.5.1 WSL support
      • 4.2 Set-up your own, local, country configuration
        • 4.2.1 Fork your own country configuration repository
        • 4.2.2 Set up administrative address divisions
          • 4.2.2.1 Prepare source file for administrative structure
          • 4.2.2.2 Prepare source file for statistics
        • 4.2.3 Set up CR offices and Health facilities
          • 4.2.3.1 Prepare source file for CRVS Office facilities
          • 4.2.3.2 Prepare source file for health facilities
        • 4.2.4 Set up employees & roles for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure role titles
        • 4.2.5 Set up application settings
          • 4.2.5.1 Managing language content
            • 4.2.5.1.1 Informant and staff notifications
          • 4.2.5.2 Configuring Metabase Dashboards
        • 4.2.6 Configure certificate templates
        • 4.2.7 Configure declaration forms
          • 4.2.7.1 Configuring an event form
        • 4.2.8 Seeding & clearing your local databases
        • 4.2.9 Countryconfig API endpoints explained
      • 4.3 Set-up a server-hosted environment
        • 4.3.1 Verify servers & create a "provision" user
        • 4.3.2 HTTPS & Networking
        • 4.3.3 Create a Github environment
          • 4.3.3.1 Environment secrets and variables explained
        • 4.3.4 Provision environments
          • 4.3.4.1 Building, pushing & releasing your countryconfig code
        • 4.3.5 Deploy
    • 5. Functional configuration
      • 5.1 Configure application settings
      • 5.2 Configure registration periods and fees
      • 5.3 Managing system users
    • 6. Quality assurance testing
    • 7. Go-live
      • 7.1 Pre-Deployment Checklist
    • 8. Operational Support
    • 9. Monitoring
      • 9.1 Application logs
      • 9.2 Infrastructure health
      • 9.3 Routine monitoring checklist
      • 9.4 Setting up alerts
      • 9.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Releases
      • v1.4.1: Release notes
      • v1.4.0 to v1.4.1 Migration notes
      • v1.4.0 Release notes
      • v1.3.* to v1.4.* Migration notes
      • v1.3.5: Release notes
      • v1.3.4: Release notes
      • v1.3.3: Release notes
      • v1.3.1: Release notes
      • v1.3.* to v1.3.* Migration notes
      • v1.3.0: Release notes
      • v1.2.* to v1.3.* Migration notes
        • v1.2 to v1.3: Form migration
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v1.1.* to v1.2.* Migration notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Interoperability roadmap
    • Product roadmap
Powered by GitBook
On this page
  • Key security points
  • Data security framework
  1. Technology

Security

PreviousLocationsNextInteroperability

Last updated 1 year ago

We treat the security of OpenCRVS and the personally identifiable citizen data it stores with utmost care.

Every release of the OpenCRVS application and infrastructure has been security penetration tested by an independent, and certified 3rd party to UK government standards.

Penetration tests of OpenCRVS have been performed by , on behalf of UNICEF, and - preferred security testing provider.

As an example, Plc conducts security assessments for public and private organisations in the form of white hat penetration testing (aka ethical hacking) to simulate an adversary attacking the system and identifying vulnerabilities that may be exploited to compromise data confidentiality, integrity and availability.

Gofore pentesters utilise proven pentesting methods of code review, automated enumeration scans via the public internet, fuzzing with diverse input, and manual tests. The security assessment was conducted in two rounds, first to identify and report vulnerabilities, and then reassessed to ensure reported vulnerabilities were resolved.

"Already from the results of the first assessment, it was evident that the OpenCRVS web application had a good security posture. The web application security fundamentals were sound."

GoFore Cyber Security Consultant

Key security points

Two factor authentication

Our server SSH access, mobile application and microservices are secure, protected by utilising . 2FA codes are sent to the user's mobile device in order log in either via SMS or Google Authenticator. These codes ensure that only users with access to authenticated hardware can access OpenCRVS.

Access controls and audit trail

User types and access controls are managed in order to segregate personally identifiable data to only to the users who need it. These user types can be set up in the Team GUI accessible by National and Local System Administrators. Every access to a specific declaration or registration is audited in order to track who viewed the data thus protecting citizen rights. All access to OpenCRVS servers and infrastructure health is logged and monitored in . SSH access to servers requires Google Authenticator 2FA.

Ansible provisioned firewall & VPN

OpenCRVS automatically provisions a secure firewall to OpenCRVS on each node. OpenCRVS should only be installed behind a separately configured and managed, government owned VPN. OpenCRVS can automatically provision a Wireguard VPN for use in pilot projects only - not for use in production.

TLS certificate

Database encryption

Data security framework

OpenCRVS is software to digitally enable civil registration processes and as such is designed to digitally store and process personally identifiable information (PII) and also create copies of official documentation including unique identifiers for citizens. It is a technical solution that is regularly penetration tested to industry standards, and where technically possible, OpenCRVS provides solutions to mitigate against common threats.

However, OpenCRVS is used within the context of human day-to-day work and interaction with the outside world. This is a world where we should expect criminals to continually adapt and attempt to gain access to valuable citizen data. The constantly evolving cyber-security landscape includes social engineering methods, machine learning and artificial intelligence. Criminals may adopt these techniques to exploit staff who use OpenCRVS and attack the servers and networks on which it is installed.

Reacting to such threats often falls outside the scope of what a technical system is capable of independently defending against. Therefore data security policies and procedures must be developed and adhered to by implementing project teams and operational staff when setting up and using OpenCRVS.

  • An understanding of data security and privacy risks.

  • An understanding of the technical steps taken in OpenCRVS to mitigate against these risks.

  • A guidance framework for the development of context-specific data security policies and procedures that should be designed and introduced by a government that has chosen to install OpenCRVS and digitise their civil registration system.

  • Security guidance for project managers and all staff involved on a temporary or continual basis in the following stages of an OpenCRVS project: a) design & implementation b) monitoring & maintenance and c) day-to-day usage of OpenCRVS.

Data security policies and procedures must be defined, implemented and updated by governments appropriate to their own contextual needs and should be informed by publicly available content specific to the subject of data security and not exclusively from this document. Some example reference links are provided in the appendix, which may prove useful for developing such policies.

OpenCRVS data is encrypted in transit via an SSL certificate that can be automatically provisioned and rotated by signed by , depending on DNS and VPN configuration.

Encryption keys to the databases, API keys and sensitive environment secrets are never stored in .env files but instead are stored in RAM in inaccessible and provided to deployment by inaccessible .

We provide a "Data Security Framework" document explained further with a video in . The purpose of this document is to provide organisations with:

CREST
CyberEssentials
MDSec
The Guardian Project
GoFore
NORAD's
GoFore
2-Factor Authentication
OAuth JWT best practices
Kibana
Traefik
LetsEncrypt
Docker Secrets
Github Secrets
this section