Legal and contractual obligations
Design your program to be compliant with all relevant national and/or local laws and regulations.
Ensure appropriate language that clearly establishes your respective roles and responsibilities for security and privacy is included in all contracts / MOUs / agreements between your organisation and any software and/or service providers.
This includes contracts/agreements with third-party service providers, who may have integrations with the solution implemented for you (e.g. SMS providers, email providers).
Such contracts/agreements should also be put in place with other government agencies, where any PII is sought to be shared with them unless they are already explicitly covered by existing laws and regulations.
Enforce these obligations, by requiring implementing agencies/support agencies/third parties/any entity being provided access to data under such contract or agreement to demonstrate compliance.
Purpose limitation and data minimisation
Identify the purpose for which a given data point is being collected, processed, and/or shared.
Ensure that the purpose is part of the mandate of your organisation, and/or that the legal basis for that purpose is established.
Do not collect data for which there is not a clear and legally defined purpose.
Define a role-access framework, wherein only roles that have a clear and legally defined purpose for access to a given data point can access it.
Notice and/or Consent
Publish a privacy policy for your organisation, which explains the purpose for collection/use/sharing of data, and which roles have access to which data.
At each point of data collection, provide clear notice to the data principal about the purpose of data collection, with links to the privacy policy for additional details.
In cases where PII is sought to be shared or used in ways not covered in the notice provided at data collection, seek and record the consent of the data principal for such additional sharing or use.
When sharing data with other entities, ensure that such entities have suitable security and privacy policies in place before such sharing.
Secure operations
To ensure security and privacy are maintained in practice, develop standard operating procedures and guidelines for all personnel to follow.
Train all personnel on your organisation’s privacy policy, standard operating procedures, and guidelines.
In particular, train personnel on the importance of login credentials/passwords, and why these must not be shared with anyone. To reduce the administrative load on personnel, explore the use of single sign-on (SSO) or similar technologies.
Establish processes to change passwords when individuals move out of a given role, or leave your organisation.
Review audit logs periodically to identify who has accessed data; use this information to periodically verify or revise role-access mapping.
Secure Deployment
Follow Installation Guidelines: Adhere to the security best practices provided in the DIGIT installation scripts and documentation.
Environment Hardening: Ensure that the deployment environment is hardened against potential threats.
Key Management: Ensure encryption key lifecycle is managed properly. Appropriate key management tools provided by cloud providers or hardware key management solutions are deployed.
Compliance
Privacy Policy: Ensure the deployment complies with relevant data protection and privacy regulations.
PII Identification: Identify all personally identifiable information (PII) and ensure these are stored as part of User and Individual Service only.
Configuration
Role Configuration: Configure roles and access based on purpose—only roles that have a purpose should be able to access that data.
Minimal Access: Provide users/roles only the minimal access required to perform their activity.
Secure Operations
Follow a robust security operations framework e.g. NIST to identify, protect, detect, respond and recover.
Intrusion Detection System (IDS): Deploy IDS to monitor network traffic for suspicious activities.
User Notification: Have procedures in place to notify users in the event of a data breach or security incident.
Data Management:
Data Archiving: Archive and/or store data keeping in mind local laws, regulations, and domain requirements. Where possible, store aggregate or anonymized data rather than PII.
Notice and Consent
Update and include a privacy policy (based on the product privacy policies), which details what information is collected, which roles have access to it, and the purpose of such access/usage.
If you have integrated with third-party service providers, such that any PII is going to be shared with them (e.g. SMS providers, email providers; other public and private agencies), this should be explicitly included in the privacy policy.
Publish a notice, with a link to the privacy policy, on the login page. Users should indicate that they have read and accepted these terms before they can log in.
Secure Application Development
Adhere to Secure Coding Standards: Manual and Automated Code Reviews to ensure OWASP guidelines are followed for secure coding to prevent vulnerabilities.
Data Storage: Leverage Persister Service when storing data and Encryption Service to encrypt sensitive data before storage.
Data Anonymization: Anonymize PII before emitting data for analysis or reporting.
Third-Party Security Testing: Conduct 3rd security penetration testing and vulnerability assessments.
Data Minimization: Collect and process only the data necessary for the functionality of the product.
Data Collection: Design forms to capture only such data from users that have well-defined purposes.
User Privacy
Purpose Limitation: Ensure users are informed about what data is collected, who will access the data and for what purpose. This information should be updated in the Terms and Conditions.
User Access: Provide citizens with the ability to view and request changes to their personal data, e.g. corrections in spelling of names, updating address, etc.
Notice and Consent
Create a privacy policy, which details what information is collected, which roles have access to it, and the purpose of such access / usage.
Publish a notice, with a link to the privacy policy, on the login page. Users should indicate that they have read and accepted these terms before they are able to login.
Security & Privacy In DIGIT
DIGIT (Digital Infrastructure for Governance and Inclusive Transformation) is an open-source platform designed to enable the delivery of public services efficiently and effectively. It consists of common services and shared data registries that various government agencies can leverage to build sector-specific solutions.
Ensuring security and privacy within DIGIT is paramount to protecting sensitive information and maintaining public trust. As an open-source platform, DIGIT can enable certain aspects of security and privacy, and provide guidelines to product and solution developers, those who install and implement the platform in production, and those who use it to deliver public services.
A Program Owner (typically a government agency) decides to implement the DIGIT platform or specific DIGIT products as its software platform for service delivery.
The Program Owner procures the services of a Solution Implementing Agency (also known as a System Integrator) to implement the DIGIT platform/products in that specific context.
The Solution Implementing Agency implements the DIGIT platform/products for the Program Owner. This includes:
Customising or extending DIGIT products as needed for that specific context.
Creating an instance of the DIGIT platform/products, on a server (cloud-based or physical) designated by the Program Owner
Configuring the products implemented in that instance to create a solution.
Conducting user acceptance testing, training, etc. with the persons (typically employees of the Program Owner) who will use those solutions.
The Program Owner directs its employees to use these solutions to perform their work/deliver services to citizens.
The Solution Implementing Agency or a Support Agency may continue to provide technical support, helpdesk services, etc. to the Program Owner, to resolve any difficulties or errors that arise when the Program Owner’s employees use these solutions.
The DIGIT platform team at eGov supports this process in multiple ways:
Periodically releasing major and minor versions, updates, and patches to the DIGIT platform. (Implementing these into the specific solution is the responsibility of the Solution Implementing Agency and/or Support Agency.)
Resolving technical issues that pertain to the platform itself. (Issues that pertain to changes made by the Solution Implementing Agency are the responsibility of the Solution Implementing Agency.)
Training and enabling employees of Solution Implementing Agencies, to enhance their capacity to develop and implement solutions using the DIGIT platform.
Advising the Program Owner on program design and governance, including the technical requirements in its procurement process, and improving the adoption of the solutions implemented.
When building, deploying, and using solutions built on the DIGIT platform, security and privacy are shared responsibilities between the DIGIT Platform, Product Developers, Solution Implementing Agencies (Systems Integrators), and Program Owners. The DIGIT Platform team incorporates key security and privacy features into the DIGIT code and installation scripts. It provides guidelines to Product Developers, Solution Implementing Agencies, and Program Owners to ensure comprehensive protection.
The responsibilities of key actors are as follows:
DIGIT Platform Team: Custodian of the DIGIT platform roadmap and building blocks. Ensures key security and privacy features are incorporated in DIGIT, and provides guidelines for other actors.
Software Product Developers: Use and extend DIGIT building blocks, possibly in combination with other DPGs or proprietary code, to create software products. Should follow guidelines for secure and privacy-protecting product development.
Solution Implementing Agencies (System Integrators): Implement (customize, configure, install, deploy, support) solutions built on DIGIT for a specific client (presumably a government agency). Should follow guidelines for secure and privacy-protecting implementation, and ensure compliance with specific local laws/regulations.
Support Providers: May be contracted to provide technical support and helpdesk services to an implementation of DIGIT for a specific client (presumably a government agency). Should follow guidelines for secure implementation, to the extent relevant to their work, and support users to follow secure operating procedures.
Program Owners: Typically a government agency. Procures the services of solution implementers to implement solutions built on DIGIT based on their needs/mandate.
The understanding of roles, levels of access, and the minimal data needed to perform a given task comes from the program owner’s administrative structures and operating procedures.
Ensure that solution implementers, support providers, and government employees using those solutions follow secure implementation guidelines and operating procedures, as well as all relevant local laws/regulations.
Secure By Default -
Default Security Settings: DIGIT is designed with default security settings that provide robust protection. While administrators can adjust these settings to fit specific needs, the out-of-the-box configuration is secure.
Minimal Privilege Principle: Users and services are granted the minimum levels of access necessary to perform their functions, reducing the risk of unauthorized access.
Authentication and Authorization -
One Time Password using SMS and Email is recommended wherever possible.
Passwords are hashed and stored in a secure database.
Password length, max invalid can be configured values for min and max password length and regex. (Default min=8, max=15 and invalidAttempts =5). Using this, we can configure the password strength.
We can also configure the maximum number of invalid attempts allowed, and the account lock duration.
Password can be changed using existing password.
Role-Based Access Control (RBAC): Implemented to ensure users have access only to necessary data and functionalities, as determined by their role.
Data Encryption -
In-Transit Encryption: All data is transmitted using HTTPS (TLS Encryption).
At-Rest Encryption: Encryption Service enables encryption of all sensitive data stored within the platform.
Secure Development Practices -
Code Reviews and Audits: Regular reviews and audits are conducted to identify and rectify vulnerabilities for all platform building blocks.
OWASP Security Guidelines: The platform development team adheres to OWASP security guidelines to prevent common vulnerabilities. These are verified during manual and automated code reviews (using AI code reviewers).
Tracking Security Updates: The platform team monitors security updates in dependent open-source libraries and software and provides upgrade releases to address any critical vulnerabilities.
Infrastructure Security -
Installation scripts implement, by default, several security best practices through automation e.g. on AWS
S3 Backend Encryption: The Terraform state is stored in an S3 bucket with encryption enabled.
VPC Configuration: The network module sets up a Virtual Private Cloud (VPC) to isolate resources and provide a secure network boundary.
Database Security: The PostgreSQL database is deployed within private subnets and security group rules are applied to control access.
IAM Role and Policy Management: IAM roles and policies are defined to grant necessary permissions while following the principle of least privilege.
OIDC Authentication: The EKS cluster is configured to use OpenID Connect (OIDC) for authentication, enhancing security through federated identity.
TLS Certificate Management: The TLS certificate resource ensures secure communication with the EKS cluster.
Kubernetes Service Accounts with IAM Roles: Service accounts in Kubernetes have specific IAM roles attached to ensure necessary AWS permissions without using static credentials.
Security Group Rules: Specific security group rules control ingress traffic to the RDS database from worker nodes only.
EKS Add-ons Management: Managed add-ons like kube-proxy, coredns, and aws-ebs-csi-driver are deployed using aws_eks_addon to keep these critical components up-to-date with security patches.
IAM Role Assumption Policy: The aws_iam_role resource includes a policy for secure and temporary access tokens using the OIDC provider.
Environment Variables and Secrets Management: Sensitive data such as database credentials and cluster names are managed as variables to avoid hard coding in configuration files.
AWS Security Group for Worker Nodes: The security group for worker nodes ensures only necessary traffic is allowed, improving the cluster’s security posture.
Backup Retention for Database: Backup retention is configured for the PostgreSQL database to ensure regular backups.
Signed Audit Logs -
Non-Repudiation: Implementation of signed audit logs to ensure actions cannot be denied after they have been performed, enhancing accountability and traceability.
The key building blocks that play a crucial role in ensuring security and privacy are as follows.
The diagram below illustrates how information flows in DIGIT, and how these services enable security and privacy during such information flow.
Click on the links below to browse through the role-specific data and privacy guidelines:
The DIGIT platform, with its suite of products and building blocks, is a . Several steps and actors (listed below) are involved in converting the DIGIT platform into a DPI – a live instance used to deliver services to citizens.
and lists down all the secure development practices.
: Ensures that no data is accessible without authentication and authorization.
: Manages users and passwords. Provides authentication services.
: Allows configuration of roles and limits access each role has to specified data and services.
: Provides the ability to encrypt and decrypt data.
: Logs all changes made to all data in a signed audit log.
