SECURITY & RESILIENCE

Security is one of the core design principles of the Bugasura platform. Security is handled at various stages in the stack to ensure redundancy in checks.

Infra Security

The entire Bugasura stack runs on the AWS infrastructure. This brings us a secure global infrastructure with superior security controls of AWS that has fine-grained identity and access controls systems combined with continuous monitoring. This in turn ensures that the right resources have the right access at all times. Our servers are hosted in a world-class AWS data center that is protected by biometric locks and 24-hour surveillance. We ensure that our application is always up to date with the latest security patches.

At the infra level, we enforce through AWS

AWS Shield

It helps manage any Distributed Denial of Service (DDoS) attacks on the servers. This is an always-on detection and automatic inline mitigation service that minimizes application downtime and latency. The AWS shield offers network and transport layer protection against DDos attacks (over Layer 3 and 4). AWS Shield is applied on the EC2, CDN and DNS services as well.

AWS Network Firewall

It is the 2nd level of protection that helps mitigate unauthorized access to the server. The firewall is configured to allow public access to the below ports.
80 and 443 - for HTTP and HTTPS based web access
xxxxx - for AES SSH access through public and private keys.

Identity Management

All access to the AWS console is restricted with the identify management access controls of AWS. Only one user is allowed complete access to the console and all other users are restricted with access to specific parts of AWS (like SES, CDN, etc).

Inbound rules (3)

Type	Protocol	Prot Range	Source
HTTPS	TCP	443	0.0.0/0
HTTP	TCP	80	0.0.0/0
Custom TCP	TCP	xxxxx	0.0.0/0

All other ports are either configured to be accessed via the local network or closed.

Server Security

At the server level, we employ various mechanisms to ensure data security and privacy.

Security patches

Security patches are regularly updated on the server to ensure the latest exploits are patched at the earliest.

UFW Firewall

In addition to the AWS Network firewall, the UFW firewall is deployed on the server to again restrict access to all ports except HTTPS and SSH.

Fail2ban

A fail2ban service also continuously runs on the server that scans for multiple requests on the open SSH and HTTPS ports. This service throttles requests from the same IP and bans multiple attempts to access the same service within a certain period of time.

Freshcalm Antivirus

The Freshclam antivirus continuously runs on the platform. This scans for any virus or malware that can be uploaded to the server from the frontend.

OpenSSH

OpenSSH is configured to disallow connections on the standard port 22(and use a non-standard port), restrict logins to only one user (non-root), support only protocol 2 logins and disallow any password-based logins. This prevents standard attacks on SSH.

Security Login

Logins are secured with only private-public key logins, all root logins are disabled and all standard users are removed from the server.

Stack Security

On the stack level, we deploy various security measures.

PHP

It is secured to disable register_globals, disable safe mode, disable magic quotes, disable opening urls, set specific directories from which code can be run, disable exploitable functions (like system, exec, etc), restrict max file sizes, and restrict session cookies to http only.

Apache2

It is regularly updated and patched to disallow directory listing, signatures and all non-user facing apps are protected via htpass.

MySQL

It is also regularly updated and patched to remove all default root users and listen only locally, preventing remote access.

SSL

All data transfer between the user and the platform is encrypted and transmitted over HTTPS using standard encryption ciphers. This ensures no network snooping of data transmitted.

Code Security

At the code level, we look at two aspects
1. User uploaded files
2. User supplied data (GET/POST data)
Both of these are potential injection points for foriegn data into the system.

User Uploaded Files

All user uploaded files are checked for filetype (using multiple methods) and file size limits. This filters out invalid and restricted file types. The file name (and extension) is then stripped of all special characters and checked against a predefined list of allowed file types, thus preventing any attacks using filenames. Post this, the file is then scanned using the Freshclam AV which removes any dangerous malwares or viruses. The final step is to move this file out of the server sandbox into the CDN. These files are then delivered only over the CDN, which prevents any user file from being executed on the server, preventing a major source of attacks. These exhaustive checks always ensure.

User Input Data

All input data (data entered by the user) is validated at multiple levels before being stored in the database. We follow the whitelisting method where only allowed rules are applied on incoming data

JS Level

data is first validated for the correct data type and length
Model Level

at the model level, the data is again revalidated to ensure the right datatype, length and any custom validations required.
DB Level

before any data is inserted into the DB, the queries are always prepared to prevent SQL injection.
Database

All fields of the database are strongly typed i.e restricted in datatype, length and other constraints to ensure only the whitelisted data is written to the database.

Session Data

To prevent URL hijacking, session data is NEVER read from the frontend. What this means is that we treat all incoming data from the frontend as dangerous. Session data like user ids, team ids, etc are never read from the incoming form data. They are always stored in server-side session cookies and used.

User Identification at DB Layer

At the query level, session data is used to separate user roles and team level access. All queries use these IDs directly from the session, preventing any cross leakage of data across stores and users.

Code Review

The Bugasura dev process has exhaustive code reviews for every push to the repository. One of the main checks in the code review is to ensure the above code level checks are always done for any incoming data. While the codebase exposes standard methods to handle all the above scenarios that developers can reuse, the code review adds an additional layer to ensure they are adhered to.

Data Security

Bugasura is built on a multi-tenancy architecture and every customer's data is separated out logically with a unique team ID so that one customer's data cannot be accessed by the other.

This team ID is always stored in the backend and is linked to the user login and thus cannot be overridden at any time. The platform is engineered and verified to ensure that it always fetches data only for the logged-in user. Per this design, no customer has access to another customer’s data.

Access Control

Bugasura has an in-built authentication module where it provides the ability for Teams to define roles for each user. The standard roles available are
OWNER - this role has complete super user access across the team and all its functionality. A team can have only owner at a time and all licenses will be managed by the owner.
ADMINS - are users who can manage all aspects of the team including managing users, projects, integrations and custom settings. They also have access to all projects across the team.
NORMAL - users can do the day to day activities across projects that they belong to. They do not have access to modify settings that impact other team or project members.
GUESTS - are users that have limited access. This role is suitable for people external to your team like customers, vendors, users, etc. Guests can be part of public projects and have access to issues they create or issues marked as public. Guests do not have access to other guest's issues or internal issues.
These roles ensure clear boundaries for users across the platform.

Backup

Bugasura platform has a multi tier, multi location backup policy

Frequency	Location	Type	Retention Time
DAILY	AWS Singapore	Disk Snapshot	7 days
6 HOURS	DigitalOcean Banglore	DB and Codebase	4 days
WEEKLY	AWS Singapore	AMI	1 month

Daily Snapshots

entire disk snapshot. These snapshots are retained for 7 days
Offsite Backup once every 6 hours

DB and codebase backup. Offsite backups are retained for 4 days.
Weekly AMI backup

complete server and disk backups. AMIs are retained for 1 month (4 versions).

While the Daily snapshots and Weekly AMI backups are on the AWS platform, the offsite backups are on a different infra provider (Digitalocean) and in a different location (Bangalore). This ensures the entire setup can be restored incase of downtime across all AWS regions.

Restore time for Daily Snapshots is 10 mins, AMI is 20 mins and Offsite Backup is 2 hours. The first two do not require any downtime.

Scalability

The platform is vertically scalable i.e by increasing the server capacity at any time. Currently the platform runs off a T2 Large instance on AWS. The time to scale up or down is less than 10 minutes with downtime.

Uptime

Uptime is managed via the Fresh Ping app. The app is used to monitor uptime of the Bugasura services and inform the team in case there are any. Multiple properties are monitored every day.