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
Governance FAQ
CLIDE Analyser
Help organization capture safety data to make better decision.
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
Web & mobile application (Android)
-
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.
No, this is not applicable.
We have interal audit process and every six months we do ccary our our security test. We have not done any third party audit but its in our road map.
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 to any third party. Due approval will be taken from company in case such need arise in future.
No, we have test environment data seperate.
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)
The password should contain minimum 8 and maximum 16 characters with at least 1 number and 1 special characters. This password policy is hardcoded.
As of now we don’t provide multifactor 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, but the facility is not present in the currnet version
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.
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
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.