The security of clients’ data.
The Security of our clients’ data is the highest priority at RISKREVELATION. We ensure that every possible security control has been applied to our client environments to ensure that the data of our clients and partners remains safe. Below is a list of some of the measures we have put in place for your assurance and to protect and defend the RISKREVELATION platform.
Hosting and Database Storage
RISKREVELATION is hosted via Amazon ECS and managed within AWS UK data centres that leverage a data centre and network architecture that is built to meet the requirements of the most security-sensitive organizations. All data is hosted and backed-up in the UK and will never lease UK shores.
Data Integrity
The RISKREVELATION Amazon ECS platform uses VPC, subnets, NAT gateways and routing to ensure the integrity of each client’s data within their environment. Docker clusters are created in their own VPCs to provide maximum network isolation.
AWS Security Groups and ECS Network Policies are used within each partner environment to handle firewalling. Firewall rules will block internal traffic between individual client environments. They are also used to restrict traffic between individual components of each stack.
* AWS security groups- https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
* AWS network Access Control List (ACL)- https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
Encrypting Data at Rest, Database
RISKREVELATION’s backend is supported by Amazon RDS RD resources to persist data. Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. After your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. For further details around the encryption at rest please see - AWS Encryption standards.
Encrypting Data at Rest, Files
Static files, such as images and other documents are persisted using AWS S3 storage. All static files are encrypted before they’re stored so while at rest they are encrypted.
Encrypting Data in Transit
All HTTP-traffic to RISKREVELATION runs over an SSL-encrypted connection and we only accept traffic on port 443. The status of our SSL configuration can be found reference to AWS SSL Status.
During a user agent’s (typically a web browser) first site visit, RISKREVELATION ends a Strict Transport Security Header (HSTS) to the user agent that ensures that all future requests should be made via HTTPS even if a link to RISKREVELATION is specified as HTTP. Additionally, we use HSTS preload, guaranteeing that requests are never – not even the very first – made over a non-encrypted connection. Cookies are also set with a secure flag.
Identity and Access Management - Multi-factor Authentication ensures only authorised and authenticated users can access your resources. You define your Users, Groups, Permissions, and Roles.
The following Detective controls - are used to identify a potential security threat or incident.
AWS GuardDuty - which will help to monitor or alert on malicious malware or unauthorized behavior.
CloudTrail – logs, continuously monitors, and retains account activity history related to actions taken on the AWS platform.
AWS Web Application Firewall - helps protect your application from common web exploits that could affect application availability, compromise security, or consume excessive security.
All Planet Pen Test traffic is proxied through CloudFlare. We leverage CloudFlare’s Web Application Firewall (WAF) to protect the site from:
· Distributed denial of service (DDoS) attacks
· Blocking of suspicious activity
· SQL injection, comment spam
· Possibility of quickly blocking IPs or entire countries
AWS ECS Compliance Standards
Third-party auditors assess the security and compliance of Amazon ECS as part of multiple AWS compliance programs. These include SOC, PCI, ISO, HIPAA, and others.
For a list of AWS services in scope of specific compliance programs, see AWS Services in Scope by Compliance Program. For general information, see AWS Compliance Programs.
More information about Amazon ECS security can be found at https://docs.aws.amazon.com/eks/latest/userguide/security.html.
Password Policy and Storage
During an account creation and password update, RISKREVELATION requires a strong password that has 12 characters or more, and contains numbers as wells as lower and uppercase letters. We do not store user passwords: we only store one-way encrypted password hashes.
If a user incorrectly enters an account password on multiple attempts, the account will be temporarily locked to prevent brute-force attacks. To further protect account access, Two-factor authentication is available to all RISKREVELATION users who use Google Authenticator, and can be turned on via the user account security settings.
Following an email change, password change or similar sensitive user account changes occur, the user is always notified in order to quickly be able to respond, should an account attack be undergoing.
Application Security
RISKREVELATION utilises the CakePHP Security Component for:
Restricting HTTP acceptance
CSRF protection
Form tampering protection
Requiring that SSL be used.
Limiting cross controller communication
Handling blackhole callbacks
Further details can be found here:
https://book.cakephp.org/2/en/core-libraries/components/security-component.html#
Organisation
We require all employees to use strong, unique passwords for RISKREVELATION accounts, and to set up two-factor authentication with each device and service where available. All RISKREVELATION employees are required to use recognized password managers to generate and store strong passwords, and are also required to encrypt local hard drives and enable screen locking for device security. All access to application admin functionalities is restricted to a subset of RISKREVELATION staff and restricted by IP and other security measures.
Proactive monitoring
RISKREVELATION provides 24/7 monitoring and alert management. RISKREVELATION will create a standard set of alerts which are posted to PagerDuty.
The following alerts are set up as default:
· An offsite website availability check on on Bytemark Nagios which checks the overall web app health.
· Security: Changes to firewall and security groups. SSL certificate expiration.
· Docker cluster checks: minimum number of pods, service response times, cluster load (host CPU and memory utilisation).
· Disk (volume) checks: disk space availability (thresholds for warning and critical).
· Database checks: failed and successful connections, query throughput to identify unusual patterns.
· Healthcheck for each service, alert to check backend 5xx error count is within normal range.
· Traditional monitoring of hosts (VMs) and dedicated database instances are less applicable when using managed services like ECS and RDS, as AWS manages compute resource
Backup
PLANETPENTEST will create and automate the backup tasks for the following.
· Terraform files, Docker manifests, Helm charts, and configuration scripts and files will be version controlled using Git/GitHub/GitLab. RISKREVELATION is open to using other version control platforms.
· Database instances in RDS are automatically backed up. Database instances running on VMs, RISKREVELATION will automate the backup process to S3/Glacier or another data store.
· Backup EBS (snapshots) and EFS volumes.
· If applicable, snapshots of Docker persistent volumes will be automated to S3/Glacier.
Patching
Managed services such as ECS and RDS are patched by AWS after confirming the maintenance schedule. RISKREVELATION will inform the client holder if critical patches will impair performance or availability.
Code Review and static code analysis
RISKREVELATION institutes strict code reviews of changes to sensitive areas of our codebase. We also employ 3rd parties for static security code analysis to detect potentially known vulnerabilities through static source code analysis.
Vulnerability Disclosure
security@riskrevelation.com
We invite anyone on the internet to notify us of issues they might find in our application to further strengthen and secure our platform. All vulnerability report submissions are read within hours of receipt, and we aim to respond to all submissions within 48 hours.
Emergency
In the event of a security breach, we have created procedures for resolute reactions, including turning off access to the web application, mass password reset and certificate rotations. If our platform is maliciously attacked, we will communicate this information to all of our users as quickly and openly as possible.