Security
Security
Security
Updated October 25, 2016
Introduction
Smartling understands that the confidentiality, integrity, and availability of our customers’ data are vital to their business operations and our own success. We use a multi-layered approach to protect that key information, constantly monitoring and improving our application, systems, and processes.
Our security practices have been evaluated as part of our SOC 2, PCI DSS Level 1, and HIPAA attestations. You can request our most recent third-party audit reports by contacting your Smartling account representative.
Physical and Environmental Security
Smartling uses Amazon Web Services (AWS) as its computing infrastructure. AWS summarizes its physical and environmental security measures as follows:
AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
AWS only provides data center access and information to employees and contractors 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 access to data centers by AWS employees is logged and audited routinely.
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 back-up power for the entire facility.
Climate and Temperature
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. Personnel and systems monitor and control temperature and humidity at appropriate levels.
Management
AWS monitors electrical, mechanical, and life support systems and equipment so that any issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.
Storage Device Decommissioning
When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual”) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.
For more information see: http://aws.amazon.com/security/
Network Security
AWS provides significant protection against traditional network security issues, which it summarizes as follows:
AWS utilizes a wide variety of automated monitoring systems to provide a high level of service performance and availability. AWS monitoring tools are designed to detect unusual or unauthorized activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts.
Systems within AWS are extensively instrumented to monitor key operational metrics. Alarms are configured to automatically notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used so personnel are always available to respond to operational issues. This includes a pager system so alarms are quickly and reliably communicated to operations personnel.
AWS security monitoring tools help identify several types of denial of service (DoS) attacks, including distributed, flooding, and software/logic attacks. When DoS attacks are identified, the AWS incident response process is initiated. In addition to the DoS prevention tools, redundant telecommunication providers at each region as well as additional capacity protect against the possibility of DoS attacks.
Distributed Denial of Service (DDoS) Attacks
AWS API endpoints are hosted on large, Internet-scale, world-class infrastructure that benefits from the same engineering expertise that has built Amazon into the world’s largest online retailer. Proprietary DDoS mitigation techniques are used. Additionally, AWS’s networks are multi-homed across a number of providers to achieve Internet access diversity.
Man in the Middle (MITM) Attacks
All of the AWS APIs are available via SSL-protected endpoints which provide server authentication. AWS AMIs automatically generate new SSH host certificates on first boot and log them to the instance’s console.
Port Scanning
When unauthorized port scanning is detected by AWS, it is stopped and blocked. Port scans of AWS instances are generally ineffective because, by default, all inbound ports on AWS instances are closed.
Packet Sniffing
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 them that is not addressed to them. Even two virtual instances that are owned by the same AWS customer located on the same physical host cannot listen to each other’s traffic.
The AWS inbound firewall service is configured in a default deny-all mode. Smartling configures the firewall to permit only the absolute minimum connectivity required to provide the Smartling services. Changes to the firewall configuration require Smartling’s X.509 certificate and key to authorize changes.
Smartling uses AWS security groups to further segment computing services as needed. For example, different security groups are configured for the production, QA, and staging environments; instances are divided into security groups based on the function they provide (load balancing, reverse proxy, etc.); and customers that require HTTPS for their Global Delivery Network websites have their SSL certificates hosted in a discrete security group.
Finally, Smartling employs an intrusion detection system above and beyond that which is provided by AWS. This system gathers logs from all network systems and creates triggers based on correlated events.
Application Security
Smartling practices test-driven software development, meaning that all code must pass a rigorous series of automated and manual tests before being deployed to production. In addition, a third party performs automated application vulnerability scanning multiple times per week. You can request the most recent third-party audit report by contacting your Smartling account representative.
Secure Transmission
All connections to the Smartling services are via TLS 1.2, including:
- User logins
- User requests
- API calls
In addition, for customers that require HTTPS for their Global Delivery Network websites, the appropriate end user requests are via the customer’s own hosted SSL certificate.
Brute Force Attack Prevention
Smartling requires that each user have his or her own account with a password of at least seven characters in length and containing at least one upper case character and at least one digit. All passwords are one-way encrypted using a custom salt. We automatically disable accounts after a certain number of consecutive failed attempts have been registered.
Cross-Site Scripting (XSS)
All user input and output is properly escaped, and automated tests verify that application output is properly escaped.
Cross-Site Request Forgery (CSRF)
All requests are checked for a valid HTTP referrer header value.
SQL Injection
All queries use properly parameterized statements.
Business Continuity
AWS data centers, called availability zones, are built in clusters in various global regions. Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk flood plains (specific flood zone categorization varies by region). In addition to discrete uninterruptable power supply (UPS) and onsite backup generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple tier-1 transit providers.
The Smartling services are deployed in multiple availability zones in each of three regions: US East (Virginia), US West (California), and Europe (Ireland). In case of failure, automated processes move traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a component or data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining components or data centers.
Smartling uses a combination of AWS storage services, including Amazon S3 and Amazon Glacier, to create and retain 24 hourly backups, 30 daily backups, and 12 monthly backups. Backups are encrypted using Advanced Encryption Standard (AES) 256-bit symmetric keys and are retained for up to two years, depending on the class of data.
Amazon S3 provides 99.999999999% durability and 99.99% availability over a given year, and data is redundantly stored on multiple devices across multiple availability zones in a region. Once stored, Amazon S3 helps maintain the durability of the objects by quickly detecting and repairing any lost redundancy. Amazon S3 also regularly verifies the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, Amazon S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data. Similarly, Amazon Glacier provides 99.999999999% durability over a given year, and data is redundantly stored on multiple devices across multiple availability zones in a region.
In addition, certain data is encrypted and backed up using the Rackspace Cloud Files service. Rackspace maintains security processes and certifications substantially similar to those of AWS. For more information see: http://www.rackspace.com/security/.
Vulnerability Reporting
Smartling takes security seriously and investigates all reported vulnerabilities. If you would like to report a vulnerability or have a security concern regarding the Smartling services, please email support@smartling.com. So that we may more effectively respond to your report, please provide any supporting material (proof-of-concept code, tool output, etc.) that would be useful in helping us understand the nature and severity of the vulnerability.
Updated October 25, 2016
Introduction
Smartling understands that the confidentiality, integrity, and availability of our customers’ data are vital to their business operations and our own success. We use a multi-layered approach to protect that key information, constantly monitoring and improving our application, systems, and processes.
Our security practices have been evaluated as part of our SOC 2, PCI DSS Level 1, and HIPAA attestations. You can request our most recent third-party audit reports by contacting your Smartling account representative.
Physical and Environmental Security
Smartling uses Amazon Web Services (AWS) as its computing infrastructure. AWS summarizes its physical and environmental security measures as follows:
AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
AWS only provides data center access and information to employees and contractors 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 access to data centers by AWS employees is logged and audited routinely.
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 back-up power for the entire facility.
Climate and Temperature
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. Personnel and systems monitor and control temperature and humidity at appropriate levels.
Management
AWS monitors electrical, mechanical, and life support systems and equipment so that any issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.
Storage Device Decommissioning
When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual”) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.
For more information see: http://aws.amazon.com/security/
Network Security
AWS provides significant protection against traditional network security issues, which it summarizes as follows:
AWS utilizes a wide variety of automated monitoring systems to provide a high level of service performance and availability. AWS monitoring tools are designed to detect unusual or unauthorized activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts.
Systems within AWS are extensively instrumented to monitor key operational metrics. Alarms are configured to automatically notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used so personnel are always available to respond to operational issues. This includes a pager system so alarms are quickly and reliably communicated to operations personnel.
AWS security monitoring tools help identify several types of denial of service (DoS) attacks, including distributed, flooding, and software/logic attacks. When DoS attacks are identified, the AWS incident response process is initiated. In addition to the DoS prevention tools, redundant telecommunication providers at each region as well as additional capacity protect against the possibility of DoS attacks.
Distributed Denial of Service (DDoS) Attacks
AWS API endpoints are hosted on large, Internet-scale, world-class infrastructure that benefits from the same engineering expertise that has built Amazon into the world’s largest online retailer. Proprietary DDoS mitigation techniques are used. Additionally, AWS’s networks are multi-homed across a number of providers to achieve Internet access diversity.
Man in the Middle (MITM) Attacks
All of the AWS APIs are available via SSL-protected endpoints which provide server authentication. AWS AMIs automatically generate new SSH host certificates on first boot and log them to the instance’s console.
Port Scanning
When unauthorized port scanning is detected by AWS, it is stopped and blocked. Port scans of AWS instances are generally ineffective because, by default, all inbound ports on AWS instances are closed.
Packet Sniffing
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 them that is not addressed to them. Even two virtual instances that are owned by the same AWS customer located on the same physical host cannot listen to each other’s traffic.
The AWS inbound firewall service is configured in a default deny-all mode. Smartling configures the firewall to permit only the absolute minimum connectivity required to provide the Smartling services. Changes to the firewall configuration require Smartling’s X.509 certificate and key to authorize changes.
Smartling uses AWS security groups to further segment computing services as needed. For example, different security groups are configured for the production, QA, and staging environments; instances are divided into security groups based on the function they provide (load balancing, reverse proxy, etc.); and customers that require HTTPS for their Global Delivery Network websites have their SSL certificates hosted in a discrete security group.
Finally, Smartling employs an intrusion detection system above and beyond that which is provided by AWS. This system gathers logs from all network systems and creates triggers based on correlated events.
Application Security
Smartling practices test-driven software development, meaning that all code must pass a rigorous series of automated and manual tests before being deployed to production. In addition, a third party performs automated application vulnerability scanning multiple times per week. You can request the most recent third-party audit report by contacting your Smartling account representative.
Secure Transmission
All connections to the Smartling services are via TLS 1.2, including:
- User logins
- User requests
- API calls
In addition, for customers that require HTTPS for their Global Delivery Network websites, the appropriate end user requests are via the customer’s own hosted SSL certificate.
Brute Force Attack Prevention
Smartling requires that each user have his or her own account with a password of at least seven characters in length and containing at least one upper case character and at least one digit. All passwords are one-way encrypted using a custom salt. We automatically disable accounts after a certain number of consecutive failed attempts have been registered.
Cross-Site Scripting (XSS)
All user input and output is properly escaped, and automated tests verify that application output is properly escaped.
Cross-Site Request Forgery (CSRF)
All requests are checked for a valid HTTP referrer header value.
SQL Injection
All queries use properly parameterized statements.
Business Continuity
AWS data centers, called availability zones, are built in clusters in various global regions. Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk flood plains (specific flood zone categorization varies by region). In addition to discrete uninterruptable power supply (UPS) and onsite backup generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple tier-1 transit providers.
The Smartling services are deployed in multiple availability zones in each of three regions: US East (Virginia), US West (California), and Europe (Ireland). In case of failure, automated processes move traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a component or data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining components or data centers.
Smartling uses a combination of AWS storage services, including Amazon S3 and Amazon Glacier, to create and retain 24 hourly backups, 30 daily backups, and 12 monthly backups. Backups are encrypted using Advanced Encryption Standard (AES) 256-bit symmetric keys and are retained for up to two years, depending on the class of data.
Amazon S3 provides 99.999999999% durability and 99.99% availability over a given year, and data is redundantly stored on multiple devices across multiple availability zones in a region. Once stored, Amazon S3 helps maintain the durability of the objects by quickly detecting and repairing any lost redundancy. Amazon S3 also regularly verifies the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, Amazon S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data. Similarly, Amazon Glacier provides 99.999999999% durability over a given year, and data is redundantly stored on multiple devices across multiple availability zones in a region.
In addition, certain data is encrypted and backed up using the Rackspace Cloud Files service. Rackspace maintains security processes and certifications substantially similar to those of AWS. For more information see: http://www.rackspace.com/security/.
Vulnerability Reporting
Smartling takes security seriously and investigates all reported vulnerabilities. If you would like to report a vulnerability or have a security concern regarding the Smartling services, please email support@smartling.com. So that we may more effectively respond to your report, please provide any supporting material (proof-of-concept code, tool output, etc.) that would be useful in helping us understand the nature and severity of the vulnerability.
Updated October 25, 2016
Introduction
Smartling understands that the confidentiality, integrity, and availability of our customers’ data are vital to their business operations and our own success. We use a multi-layered approach to protect that key information, constantly monitoring and improving our application, systems, and processes.
Our security practices have been evaluated as part of our SOC 2, PCI DSS Level 1, and HIPAA attestations. You can request our most recent third-party audit reports by contacting your Smartling account representative.
Physical and Environmental Security
Smartling uses Amazon Web Services (AWS) as its computing infrastructure. AWS summarizes its physical and environmental security measures as follows:
AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
AWS only provides data center access and information to employees and contractors 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 access to data centers by AWS employees is logged and audited routinely.
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 back-up power for the entire facility.
Climate and Temperature
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. Personnel and systems monitor and control temperature and humidity at appropriate levels.
Management
AWS monitors electrical, mechanical, and life support systems and equipment so that any issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.
Storage Device Decommissioning
When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual”) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.
For more information see: http://aws.amazon.com/security/
Network Security
AWS provides significant protection against traditional network security issues, which it summarizes as follows:
AWS utilizes a wide variety of automated monitoring systems to provide a high level of service performance and availability. AWS monitoring tools are designed to detect unusual or unauthorized activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts.
Systems within AWS are extensively instrumented to monitor key operational metrics. Alarms are configured to automatically notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used so personnel are always available to respond to operational issues. This includes a pager system so alarms are quickly and reliably communicated to operations personnel.
AWS security monitoring tools help identify several types of denial of service (DoS) attacks, including distributed, flooding, and software/logic attacks. When DoS attacks are identified, the AWS incident response process is initiated. In addition to the DoS prevention tools, redundant telecommunication providers at each region as well as additional capacity protect against the possibility of DoS attacks.
Distributed Denial of Service (DDoS) Attacks
AWS API endpoints are hosted on large, Internet-scale, world-class infrastructure that benefits from the same engineering expertise that has built Amazon into the world’s largest online retailer. Proprietary DDoS mitigation techniques are used. Additionally, AWS’s networks are multi-homed across a number of providers to achieve Internet access diversity.
Man in the Middle (MITM) Attacks
All of the AWS APIs are available via SSL-protected endpoints which provide server authentication. AWS AMIs automatically generate new SSH host certificates on first boot and log them to the instance’s console.
Port Scanning
When unauthorized port scanning is detected by AWS, it is stopped and blocked. Port scans of AWS instances are generally ineffective because, by default, all inbound ports on AWS instances are closed.
Packet Sniffing
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 them that is not addressed to them. Even two virtual instances that are owned by the same AWS customer located on the same physical host cannot listen to each other’s traffic.
The AWS inbound firewall service is configured in a default deny-all mode. Smartling configures the firewall to permit only the absolute minimum connectivity required to provide the Smartling services. Changes to the firewall configuration require Smartling’s X.509 certificate and key to authorize changes.
Smartling uses AWS security groups to further segment computing services as needed. For example, different security groups are configured for the production, QA, and staging environments; instances are divided into security groups based on the function they provide (load balancing, reverse proxy, etc.); and customers that require HTTPS for their Global Delivery Network websites have their SSL certificates hosted in a discrete security group.
Finally, Smartling employs an intrusion detection system above and beyond that which is provided by AWS. This system gathers logs from all network systems and creates triggers based on correlated events.
Application Security
Smartling practices test-driven software development, meaning that all code must pass a rigorous series of automated and manual tests before being deployed to production. In addition, a third party performs automated application vulnerability scanning multiple times per week. You can request the most recent third-party audit report by contacting your Smartling account representative.
Secure Transmission
All connections to the Smartling services are via TLS 1.2, including:
- User logins
- User requests
- API calls
In addition, for customers that require HTTPS for their Global Delivery Network websites, the appropriate end user requests are via the customer’s own hosted SSL certificate.
Brute Force Attack Prevention
Smartling requires that each user have his or her own account with a password of at least seven characters in length and containing at least one upper case character and at least one digit. All passwords are one-way encrypted using a custom salt. We automatically disable accounts after a certain number of consecutive failed attempts have been registered.
Cross-Site Scripting (XSS)
All user input and output is properly escaped, and automated tests verify that application output is properly escaped.
Cross-Site Request Forgery (CSRF)
All requests are checked for a valid HTTP referrer header value.
SQL Injection
All queries use properly parameterized statements.
Business Continuity
AWS data centers, called availability zones, are built in clusters in various global regions. Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk flood plains (specific flood zone categorization varies by region). In addition to discrete uninterruptable power supply (UPS) and onsite backup generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple tier-1 transit providers.
The Smartling services are deployed in multiple availability zones in each of three regions: US East (Virginia), US West (California), and Europe (Ireland). In case of failure, automated processes move traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a component or data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining components or data centers.
Smartling uses a combination of AWS storage services, including Amazon S3 and Amazon Glacier, to create and retain 24 hourly backups, 30 daily backups, and 12 monthly backups. Backups are encrypted using Advanced Encryption Standard (AES) 256-bit symmetric keys and are retained for up to two years, depending on the class of data.
Amazon S3 provides 99.999999999% durability and 99.99% availability over a given year, and data is redundantly stored on multiple devices across multiple availability zones in a region. Once stored, Amazon S3 helps maintain the durability of the objects by quickly detecting and repairing any lost redundancy. Amazon S3 also regularly verifies the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, Amazon S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data. Similarly, Amazon Glacier provides 99.999999999% durability over a given year, and data is redundantly stored on multiple devices across multiple availability zones in a region.
In addition, certain data is encrypted and backed up using the Rackspace Cloud Files service. Rackspace maintains security processes and certifications substantially similar to those of AWS. For more information see: http://www.rackspace.com/security/.
Vulnerability Reporting
Smartling takes security seriously and investigates all reported vulnerabilities. If you would like to report a vulnerability or have a security concern regarding the Smartling services, please email support@smartling.com. So that we may more effectively respond to your report, please provide any supporting material (proof-of-concept code, tool output, etc.) that would be useful in helping us understand the nature and severity of the vulnerability.