Since Aivo is offered as a service (SaaS), no infrastructure is required from the client, we handle the infrastructure to ensure that your data is safe and secure. With no headaches around installing hardware or software, companies using Aivo can focus on supporting their customers.
Main reasons and advantages why we offer Aivo as a service (SaaS):
- Redundancy and high availability of the information
- Dynamic scalability of infrastructure that enables to meet peaks in demand
- Access to frequent updates in the application
- High security levels and disasters prevention
- Encrypted Information
- SLA 99.9% (check it in http://sla.aivo.co)
Aivo's Commitment to Trust
Trust is a core principle of Aivo. We’re committed to building reliable and secure systems that you can depend on for your business. And we’re committed to transparency around our operations at our Trust Site (sla.aivo.co) so you can provide the highest level of support.
Security Framework Compliance and Auditing
Aivo leverages Amazon Web Services (AWS) for our computing infrastructure. AWS has achieved ISO 27001 certification and has successfully completed multiple SSAE 16 audits. For more detail on AWS security, please refer to http://aws.amazon.com/security/.
Physical Security of Facilities
Aivo employees do not have physical access of any kind to our production facilities, as all of our infrastructure is in the cloud at AWS.
Amazon has many years of experience in designing, constructing, and operating large-scale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities, and critical locations have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication no fewer than three times to access Amazon Web Services Security data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
Amazon only provides data center access and information to employees who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical and electronic access to data centers by Amazon employees is logged and audited routinely.
Infrastructure Architecture
Environmental Safeguards
Fire Detection and Suppression
Automatic fire detection and suppression equipment has been installed to reduce risk. The fire detection system utilizes smoke detection sensors in all data center environments, mechanical and electrical infrastructure spaces, chiller rooms and generator equipment rooms. These areas are protected by either wet-pipe, double-interlocked pre-action, or gaseous sprinkler systems.
Power
The data center electrical power systems are designed to be fully redundant and maintainable without impact to operations, 24 hours a day, and seven days a week. Uninterruptible Power Supply (UPS) units provide back-up power in the event of an electrical failure for critical and essential loads in the facility. Data centers use generators to provide backup power for the entire facility.
Climate and Temperature Control
Climate control is required to maintain a constant operating temperature for servers and other hardware, which prevents overheating and reduces the possibility of service outages. Data centers are conditioned to maintain atmospheric conditions at optimal levels. Monitoring systems and data center personnel ensure temperature and humidity are at the appropriate levels.
Management
Data center staff monitor electrical, mechanical and life support systems and equipment so issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.
For additional information see: https://aws.amazon.com/securit
Network Security
We have deployed a Virtual Private Cloud (VPC) letting us provision a logically isolated section of the Amazon Web Services (AWS) cloud where we can launch resources in a virtual network. We have complete control over our virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.
VPC implementation also allow us to customize our network configuration having resources in a public-facing subnet and place our backend systems such as databases or application servers in a private-facing subnet with no Internet access. We've also multiple layers of security, including security groups and network access control lists, to control access to each subnet.
The firewall is configured in a default deny mode and Aivo explicitly opens ports to allow inbound traffic. The traffic may be restricted by protocol, by service port, as well as by source IP address (individual IP or CIDR block). The firewall is configured to permit only the absolute minimum connectivity required to provide the Aivo services. The AWS network provides significant protection against traditional network security issues. The following are a few examples:
- Distributed Denial Of Service (DDoS) Attacks: AWS API endpoints are hosted on the same Internet-scale, world class infrastructure that supports the Amazon.com retail site. Standard DDoS mitigation techniques such as syn cookies and connection limiting are used. To further mitigate the effect of potential DDoS attacks, Amazon maintains internal bandwidth which exceeds its provider-supplied Internet bandwidth.
- Man In the Middle (MITM) Attacks: All of the AWS APIs are available via SSL-protected endpoints which provides server authentication. Amazon EC2 AMIs automatically generate new SSH host keys on first boot and log them to the console. Aivo then uses the secure APIs to call the console and access the host keys before logging into the instance for the first time.
- IP Spoofing: Amazon EC2 instances cannot send spoofed traffic. The Amazon-controlled, host-based firewall infrastructure will not permit an instance to send traffic with a source IP or MAC address other than its own.
- Port Scanning: Port scans by Amazon EC2 customers are a violation of the Amazon EC2 Acceptable Use Policy (AUP). Violations of the AUP are taken seriously, and every reported violation is investigated. When Port scanning is detected it is stopped and blocked. Port scans of Amazon EC2 instances are generally ineffective because, by default, all inbound ports on Amazon EC2 instances are closed.
- Packet sniffing by other tenants: It is not possible for a virtual instance running in promiscuous mode to receive or “sniff” traffic that is intended for a different virtual instance. The hypervisor will not deliver any traffic to instances that is not addressed to them. This includes two virtual instances that are owned by the same customer, even if they are located on the same physical host. Attacks such as ARP cache poisoning do not work within EC2.
The Operations Team has the ability to change firewall rules.
Host Security
Data center staff monitor electrical, mechanical and life support systems and equipment so issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.
We are leveraging AWS for all of our computing infrastructure. AWS owns the physical hardware. AWS provides security groups to limit access to devices. We fully utilize security groups to limit access to our computing resources.
Our production environment is completely separate from the other environments, including development and QA. The production environment is in the west region while all of the other environments are in the east region.
AWS provides Identity Access Management (IAM) to control access to AWS resources. We use AWS IAM to manage separate, restrictive AWS credentials for each of our environments. This limits the AWS services available to each environment and compartmentalizes them.
We also use AWS IAM to delegate monitoring and management capabilities to operations staff and prevent destructive actions.
SSH keys are required to gain console access to our servers, in any of the environments.
Individually identifiable RSA key pairs are used for SSH access, and root login is disabled. This insures that there is a complete audit trail via sudo from a specific action back to the specific individual who triggered that action.
We adhere to strong password policies and require that all RSA private keys be encrypted with a compliant password.
Automated processes are in place on each host that monitoring for unauthorized login attempts, with the offending IP address being automatically blacklisted and an alert being generated.
The servers are built using repeatable build processes powered by Puppet, which in turn keeps its configuration within a private GitHub repository. All changes to the production environment pass through a peer-review change management process, with all changes logged to a central ticket system.
Application Security
Vulnerability Scanning / Penetration Testing
We have 3rd parties providers periodically scanning and monitoring our apps and network to find vulnerabilities. This help us to prevent potential security problems on our apps, servers and network layers. The scanners includes:
- Scan web applications to look for known security vulnerabilities including cross-site scripting or SQL injection.
- Scan also for insecure server configurations.
- Test authentication via several methods including Basic, Digest, Kerberos or NTLM.
- Test for commonly known database injections contained within php, jsp, asp SQL and XPath Injections.
- Scan binary code (also known as ‘compiled’ or ‘byte’ code) which can contain known vulnerabilities.
Encryption
We have implemented strong encryption via SSL in our application. By using encryption, we minimize the chances of someone possibly intercepting username/password combinations and/or other sensitive information. Areas where we utilize SSL include:
- All application logins require SSL. Any area which requires a user to log into our system also requires that SSL is used.
- The administrative, agent, analytics and API interfaces all leverage and requires SSL throughout.
Brute Force Attack Prevention
In order to minimize brute force login attacks, we automatically disable accounts for a five-minute period after five consecutive failed attempts have been registered. If we ever determine that this is a possible area of concern, we can easily increase the lockout period or decrease the number of consecutive failures via configuration. Expected Points of Entry:
+ Admin Site Login
- SSL encryption is required
- Brute force lockout (5 attempts with 5 minute backoff)
+ XSS
- All public forms are sanitized to prevent XSS
- Agent email HTML view is sanitized to prevent malicious email attacks
+ CSRF
- GET JSON Requests – does not protect forgery for GET requests out of the box. As a result, we have added authenticity tokens to all sensitive Agent and Admin GET JSON requests with corresponding verification on inbound requests.
- POST/PUT/DELETE Requests – use support for CSRF token checks for all POST/PUT/DELETE verbs
+ SQL Injection
- We use prepared statements within our apps to avoid SQL injection issues
+ Attachment filenames
- Attachments are saved to a generated GUID temp file before uploading to S3. This avoids issues associated with saving/overwriting files with relative file paths
Passwords
Passwords are used for different purposes. Some of the more common uses include: user level accounts, web accounts, email accounts, screen saver protection, etc. Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only used once), AIVO has mandatory format validation passwords for most of the sensitive components assuring strong passwords all the time. Strong passwords have the following characteristics:
- Contain both upper and lower case characters (e.g.a-z, A-Z)
- Have digits and punctuation characters as well as letters (e.g. 0-9, !@#$%^&*()_+|~=\`{}[]:";'<>?,./)
- Are at least eight characters long.
- Are not words in any language, slang, dialect, jargon, etc.
- Are not based on personal information, names of family, etc
Passwords & OAuth tokens to external services are encrypted in the database. The encryption keys are stored outside of the codebase and outside of the access from anyone without production access. Each are encrypted with a site encryption key, which is itself encrypted with a master key that we will rotate periodically.
Data Storage & Retention Policies
Data is generally stored in a MySQL Database. All data (other than passwords and authentication strings) are encrypted. The production MySQL database is configured with high availability with data replicated to multiple, redundant instances. The database is backed up on a nightly basis with encrypted backup copies being shipped to secure offsite storage. In addition to our usage of this data in production we also occasionally take a copy of the data and load it in our testing environments. These copies are scrubbed of any sensitive or personally-identifiable information before being used for testing or development purposes.
Incident Management Policies
We have implemented more than three thousand service checks, some of which run as often as every minute, which will quickly alert us to abnormal activity. All system events are logged to a central logging service, and any unusual events are flagged for review by a member of the operations team. All user actions are logged to a secure access log which records the user information, timestamp, IP address, browser, and resource accessed. This information can later be quickly retrieved in the event that a forensic investigation is required. We plan on always notifying our customers of security incidents as soon as it is safe and prudent to do so, and will share any relevant information to allow our customers to take the necessary actions on their side.
Access to Customer Data
Aivo staff does not access or interact with customer data or applications as part of normal operations. There may be cases where Aivo is requested to interact with customer data or applications at the request of the customer for support purposes or where required by law. Customer data is access controlled and all access by Aivo staff is accompanied by customer approval or government mandate, reason for access, actions taken by staff, and support start and end time.
Employee Screening & Policies
As a condition of employment all Aivo employees undergo pre-employment background checks and agree to company policies including security and acceptable use policies.
Do you have any security concern? Please let us know!
Trust is a core principles of Aivo — so your security is of utmost importance to us. We’re constantly working to make sure our system is as secure as possible. If we missed something that you uncover, we are committed to verifying and fixing the issue as soon as possible. Please submit the issue to support@aivo.co and once we verify the issue, we’ll send you some Aivo swag as a sign of our appreciation!