Application Security FAQ
Solution Architect
As we can see in the Solution Architect diagram we have web application user as well as mobile application user.
-
First web/mobile application user will send HTTPS request to the REST APIs which will be developed in Java.
-
On the cloud, we will first authenticate the user before accessing API.
-
Once API authentication will be done the user can access API as per request.
-
As per HTTPS request to REST APIs, we will store the user uploads in AWS S3 bucket or equivalent (file storage server) and data in MySQL database.
Access Token
Every request made by the user is authenticated by using a JW token. A authorisation request is sent to the server by an API and it is managed session per session.
This makes the application security more stronger.
-
Progressive web application OR Native mobile app?
- Native Mobile App -
How we will share the app with the user?
- Apps will be publicly available. TOI users will be able to download and installed. Our system will identify the user as per login ID, and access to the client instance will be provided to the user. It is a generic app but can be white-labeled after login.
Architecture Diagram
The application is three tire structure and the architecture diagram for the same is shown here
Security Certification for application
ISO/IEC 27001:2022
ISO/IEC 27017-2015
GDPR - Data Protection
ISO/IEC 20000-1:2018
ISO 9001:2015
VAPT - Web Application
VAPT - Android App
VAPT - IOS App
Bug Resolution Matrix
All incidents shall be classified as follows:
|
Severity Level |
Description |
Initial Response Time |
Resolution Target |
|
Critical (P1) |
System unavailable or major functionality failure impacting all users |
2 business hours |
24–48 hours |
|
High (P2) |
Major feature impaired with no workaround |
4 business hours |
3–5 business days |
|
Medium (P3) |
Partial functionality issue with workaround available |
1 business day |
7–10 business days |
|
Low (P4) |
Minor issue, cosmetic defect |
2 business days |
Next scheduled release |
Resolution timelines apply to standard product functionality only. Custom developments may require separate estimation. As per the above matrix, 99% of the issues will be resolved within the defined timelines. However, in case any issue is not resolved within the specified time frame, the CLIDE team will keep the Client team informed with regular updates on the progress and status.
Escalation Matrix
If issues are not resolved within defined timelines, escalation may occur as follows:
- Level 1 – Support Team
- Level 2 – Technical Lead / Product Manager
- Level 3 – Head of Engineering
- Level 4 – Executive Management
Escalation requests must reference the existing ticket number.
Application Availability & Scheduled Maintenance
CLIDE Analyser is designed to deliver high availability and reliable performance for all users. We target 99.9% service availability (excluding scheduled maintenance). Planned maintenance activities, including security updates, infrastructure upgrades, and performance enhancements, are scheduled during non-business hours wherever possible and are communicated to customers in advance. Any unexpected service disruption is monitored and addressed promptly by our technical support team to restore normal operations at the earliest opportunity while ensuring the security and integrity of customer data.
Governance FAQ
CLIDE Analyser EHS + ESG + BRSR
Help organization capture safety data to make data driven decision to achieve zero harm vision.
Its multi tenant application with monolithic architecture
Views
-
Cross-Site Scripting
-
HTTPS
-
JWT token base Authentication & Authorization
-
No GET requests are allowed
Business Layer
-
Access Control List for application access
-
JWT token base Authentication & Authorization
-
Login attempt logs
-
User logs
Access Layer
-
Firewall
-
Separate environments for development & testing and separate from production
-
Monitoring logs
DB Store
-
Separate Database Server
-
Data Encryption for sensitive data
-
Secured database user access
-
Internal Database backup with Disaster Recovery Plan
The application operates independently and no integration with third party is required.
Web & mobile application (Android & IOS)
SAAS - Software as a Service
-
Cross-Site Scripting
-
HTTPS
-
JWT token base Authentication & Authorization
-
No GET requests are allowed
-
Firewall
-
Access Control List for application access
-
Separate environments for development & testing and separate from production
-
Separate Database Server
-
Data Encryption for sensitive data
-
Secured database user access
-
Internal Database backup with Disaster Recovery Plan
Application can not be hosted on on-premises
Application Development platform
-
Jersey - Java Framework
Frontend
-
React Native v0.60.5
-
Reacj JS v16.11.0
Database
-
MySql v5.7 (AWS RDS)
Version Control
-
GIT
Server:
-
Operating System - Ubuntu 18.04.3 LTS
-
Hosting Interface - AWS EC2
-
Server: Apache/2.4.29, Apache Tomcat/9.0.24
Yes, we are using stable versions for all technology stack. Technologies hardening & code review is performed. We have followed our internal audit & code review guidelines for the same.
Yes, application is GDPR compliant
We have internal audit process and every six months we do ccary our our security test. VAPT is done every year. Till now two VAPT testing is done on web and both the mobile apps for android and IOS
Yes, we are using stable versions for all technology stack. Technologies hardening & code review is performed. We have followed our internal audit & code review guidelines for the same.
APIs uses JWT (JSON Web Token) for authentication purpose. There is a secret Key used to encrypt the JSON formatted Data which primarily includes the user-id. Now an encryption of data with the Key generates the token that is sent to the client and used in every request. Every time, the client sends in the request with the token the
There is a secret Key used to encrypt the JSON formatted Data which server tries to decrypt it with the Key, if it can, it gets the user-id from the JSON Data which corresponds to the user. Very useful in secured API connectivity.
Data Management FAQ
The application receives UAUC, NM and Safety Audit observation data, later on by analyzing this data it produce the stats, future predictions which help in decision making in the organization. Data is in the form of text, image, voice and video stored over secured servers.
Data which is sensitive like user password session handling are considered as sensitive and stored in encrypted format. Other than these no other data is classificated as sensitive.
Yes, we are storing password in encrypted format. We will be using encryption if any sensitive data identified
AWS Backup(AWS RDS) and internal backup on S3 storage
Data will be shared on password protected temporary link to download with the time limit - link will have expiry limit.
After successfully transfer of data & approval of email for data purging, in next 72hrs data will be purged permanently. Yes, we will provide purging certificate.
Currently no data is being used for any third party. Due approval will be taken from company in case such need arise in future.
No, we have test environment data separate.
Access Management FAQ
User can be created using an admin portal, later added user in the system can create his password and start using the web application as well as mobile application (Android & IOS)
The password should contain minimum 8 and maximum 16 characters with at least 1 number and 1 special characters. This password policy is hardcoded.
Yes the application provide multi-factor authentication.
Yes, an application provides role base access in entire application
Monitoring inactive user is done through admin which is with organization. The review and deletion of inactive user has to be done by organization and we don’t have access to user account and no one can from CLIDE can access those account.
User Management, all master data management, services & project management, user assignment to projects & services, Best Performer rule, Module Assignment for each & every project, All form setting to customise the workflow as per organization need.
No, we dont maintain vendor account in client database.
Yes, we offer SSO integration is is part of the admin setting.
As the application is available over SAAS, no access is needed from company for PRD support.
Yes, Client will have to white list the IP’s, and few other settings.
Incident Management FAQ
We have incident management online system and login for the same will be given to admin to report the issue. The issue can be tracked on real time till it get resolved.
A separate SPOC and process document will be shared for the SOPs. Data Breach Policy
As of now we don’t have any compensation policy for data leak.
Monitoring FAQ
Yes, you can request for the same and our key account manager will provide you the details.
Currentl the application has Login logs / user activity logs / server logs
No. only on request it can be provided.
Vulnerabilities / bugs identified by client will be checked by our QA team to confirm if thet are bugs or vulnerabilities. Post confirmation based on the risk level a priority will be given to resolve the issues.
BCP FAQ
We have the Backup and Recovery process which mainatin the RPT and RPO objectives. A periodic backup cycle is mainatined to ensure less data is lost. As we offer the application on AWS cloud platform a standrad tools are deployed for data backup and recovery.
Yes we communicate regularly about stratup and shutdown to client.
Yes, we do it for in some known cases and whenever we come across new cases we do recovery of the failed transactions.
Standard AWS disaster recovery process will be in place
Recovery Point Objective (RPO) — The acceptable amount of data loss measured in time. For example, if a disaster occurs at 12:00 PM (noon) and the RPO is one hour, the system should recover all data that was in the system before 11:00 AM. Data loss will span only one hour, between 11:00 AM and 12:00 PM (noon).
Recovery Time Objective (RTO) — The time it takes after a disruption to restore a business process to its service level, as defined by the operational level agreement (OLA). For example, if a disaster occurs at 12:00 PM (noon) and the RTO is eight hours, the DR process should restore the business process to the acceptable service level by 8:00 pm.
Currently system till date data which can be sliced on application view level. For example, yearly filters can be provided so that data for particular year only will be visible.