Mammoth provides you the benefits of a highly secure cloud architecture. Everything we do at Mammoth is geared at every step with a philosophy of security first. This document outlines various aspects of data security at Mammoth.
Data security is a shared responsibility. There are aspects of data security that Mammoth takes care of. There are also aspects of security that you need to be aware of. Besides illustrating the data security policy and practices at Mammoth, we would also make you aware of your role in keeping your data secure.
Application layer security
Mammoth is a cloud platform designed as Software as a service (SaaS). You typically access Mammoth through your browser and at times using the Application programmer interface (API). All the data exchange between client (browser/scripts) and Mammoth is encrypted. The encryption uses Transport layer security(TLS) protocol using Secure hash algorithm (SHA) 256 bit algorithm with a 128 bit encryption key which practically makes reading any data over the network impossible. You can see the details of encryption using your browser information bar that describes the encryption details. Read more about TLS and SHA
Login and API tokens
All access to Mammoth is controlled through login. Login process generates an API token. The token is specific to the user who has logged in and gives the user a controlled access to the data authorized for this user only. Tokens can be made to expire after few minutes of inactivity in a browser or can be to stay longer if the user chooses ‘Remember me’ on login. In either of the case, It is user responsibility to keep the token secure while it is valid. This implies not leaving the laptop unattended, not saving the passwords with browser account etc. You can log in from any number of devices. Mammoth would send you periodic report on devices and activities. Mammoth also show account activity in the bottom bar of the application.
Accessing third party sources for sourcing data
Mammoth allows you to pull your data from third party sources through APIs or allows you to connect to your database servers over internet.
Mammoth provides integration to only those third party APIs which implement TLS. Most of the services on the web are compliant with this need.
When you connect to your own database system through Mammoth third party console, it is your responsibility to ensure that appropriate encryption is enabled on the database server side. Mammoth would allow you to provide secure connections over network to your third party through supported mechanisms as long as you have enabled the corresponding requirements on your database server side. Not doing a secure connection to the database server makes you vulnerable to sniffing over network.
Mammoth has a robust permission model designed at its core to support data security. User roles are designed in a way that only those who need to have access to data get it. Roles like billing or user management for account can only do that and not be able to access data. Datasets have to be explicitly shared with other users in the same account for it to be accessible to those other users.
Our deployments are on Amazon web services (AWS). This means you get all the benefits of world class compliance programs on physical data center, netwok and storage security. The AWS infrastructure puts strong safeguards in place to help protect privacy of data.
AWS’s security measures are verified by independent auditors who ensure that specific security controls are in place and are functioning properly. AWS has achieved ISO 27001 certification for IT security techniques, and have been validated as a Level 1 service provider under the Payment Card Industry’s Data Security Standard. AWS undergoes annual SOC 1 audits.
Read more about AWS compliance programs here
AWS provides the benefits of its security regime as configurations through following controls
- Identity and access management (IAM)
- Multi factor authentication
- Key management
- Encryption for storage at various level (EBS, S3, EFS) etc
- Multiple access control provisions through network ACLs, Security groups, Virtual private cloud (VPC)
Mammoth puts the complete gamut of security features of AWS to full use.
- Our deployments sit in Virtual private cloud (VPC). Only the public facing server has a public ip address. All instances are on a private network within the VPC. This means that the servers just cannot be accessed from outside other than through specific application layer ports for https access.
- Our production deployments are completely isolated from all other development servers and protected through IAM security policy. The security policy is designed to deny access to unauthorized individuals.
- Each of the server is further protected through most stringent, minimal allow permissions on security groups and minimal allowances on Network access control lists (ACLs).
Cloud security alliance (CSA) guidelines and its Cloud control matrix constitute the most comprehensive guidelines for ensuring data security in cloud. Mammoth applies all applicable controls prescribed in the control matrix. All data center, network and general physical infrastructure related guidelines are handled by AWS
Protection from access to our production servers
All access to production server is controlled and monitored by Security Council. A very small number of authorized users can access these servers with due permission from the council. Access keys are replaced periodically.
All the maintenance work on the servers is carried out through continuous deployment systems which provide control only for maintenance but not accessing those machines. All kinds of trace/performance/usage monitoring does not require any direct access to these systems. Logs are sanitized for making sure no user/data specific information is embedded in those logs. Control and monitoring is performed remotely.
In those rarest of the rare cases where the machines need to be accessed, a due approval is obtained from security council to access the servers. All activity during such access is monitored.
Protecting data at rest
Your data sits in a databases. Each customer account is assigned a separate database of its own with its own password. Databases are stored as files in volumes in AWS. These volumes are kept encrypted. This encryption make sure that if these disks are isolated and re-mounted elsewhere they cannot be read. Also all data exchanged over network between the volume and the instance is also encrypted. The decryption keys are part of the isolated production deployment inaccessible to anyone other than individuals authorized by security council.
Responses to security breach
Our security incident response policy handles our response to the incidents related to security. A short summary of the policy is provided here
- Incident capture and classification: Incidents are captured from various probes with a special lookout for any unusual activity. This is a regular monitoring activity on the infrastructure performed by a team trained for analyzing security breaches
- Incident rectification: All interesting events requiring rectification are escalated to the highest levels in engineering, marketing, public relations for respective actions. Technical rectification action is identified and implemented. If the incident response requires any shutdown or downtime of the infrastructure, it is carried out immediately. The impact of the breach is ascertained by analyzing past activity through various forensic tools.
- Incident reporting: All incidents involving any user data breach are classified as such and public relations is mandated to bring it to the notice of the user to take any corrective action on their part with a clear guidance on the possible damage risk mitigation advice for the customers.
Organizational best practices
At Mammoth we follow the best programming and continuous delivery practices. Version control, code reviews, automation are fundamental to the work we do. The changes are made and reviewed in small chunks and all reviews look for any signs of potential data security breaches. For all regular functions the focus is always to make process completely automation driven so that no human intervention is required.
Every security system is required to have a root of trust in a few individuals in an organization. The root of trust is controlled through a Security council. Security council controls the keys, defines and approves security policy and ensures compliance and best practices towards maintaining a data secure environment at Mammoth. Security council continuously reviews the organizational practices in following areas
- Application and interface security
- Audit assurance and compliance
- Business continuity management
- Change control and configuration management
- Data security and information life-cycle management
- Encryption and key management
- Data governance and risk management
- Human resource policy with focus on data security
- Identity and access management
- Infrastructure and virtualization security
- Interoperability and portability
- Mobility and security
- Security incident management
- Threat and vulnerability management