Security
Security and Privacy are Shared Responsibilities
When building, deploying, and using solutions built on the DRISTI, security and privacy are shared responsibilities between the DRISTI, Product Developers, Solution Implementing Agencies (Systems Integrators), and Program Owners. The DRISTI team incorporates key security and privacy features into the DRISTI 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:
DRISTI Team: Custodian of the DRISTI roadmap and building blocks. Ensures key security and privacy features are incorporated in DRISTI, and provides guidelines for other actors.
Software Product Developers: Use and extend DRISTI 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 (customise, configure, install, deploy, support) solutions built on DRISTI 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 DRISTI 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 DRISTI 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.
DRISTI Practices
Secure By Design
Default Security Settings: DRISTI 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 Authorisation
One Time Password using SMS and Email are used 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 DRISTI.
Secure Development Practices
Since the DRISTI is built on top of DIGIT, all secure development practices mentioned in the DIGIT Security Handbook and DIGIT Security Checklist have been followed.
Code Reviews and Audits: Regular reviews and audits are conducted to identify and rectify vulnerabilities for all DRISTI building blocks.
OWASP Security Guidelines: The DRISTI 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 DRISTI 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.
Last updated