Sapper is committed to providing a highly secure and reliable integration and business automation service. This includes maintaining the confidentiality of its customers’ information and ensuring that customers’ information will be available when it is needed. To achieve this we use proven, tested, best-in-class security tools, technologies, practices and procedures.
Hosting Environment and Physical Security
Sapper is hosted on public cloud infrastructure from Amazon Web Services (AWS) . Amazon maintains high standards of security for their data centers. You can read further about AWS security here:
The Sapper website is only accessible over HTTPS. Traffic over HTTPS is encrypted and is protected from interception by unauthorized third parties. Sapper follows current best practices for security, including the use of strong encryption algorithms with a key length of at least 128 bits.
Sapper also uses secure protocols for communication with third-party systems: usually HTTPS, but other protocols such as SFTP and FTPS are also supported. HTTPS connections are secured using TLS 1.2/1.3. Transmission using TLS 1.1 and lower is not supported. For on-premise systems, access requires the installation of an on premises agent behind the firewall, which communicates outbound to Sapper over an encrypted link, using TLS 1.2.
Sapper uses a multi-tier architecture that segregates internal application systems from the public Internet. Public traffic to the website passes through a Web Application Firewall (WAF) and then is routed to interior systems running on private subnets. Interior as well as exterior network traffic uses secure, encrypted protocols. All network access, both within the datacenter and between the datacenter and outside services, is restricted by firewall and routing rules. Network access is recorded into a centralized secure logging system.
Sapper product and all files ingested into Sapper are protected by anti-virus.
Sapper provides multiple layers of protection for Customer data.
Sapper provides fine-grained controls to determine what data is stored and what is not. Customers can choose to completely turn off storage of all customer data.
Sapper has a fully configurable Retention Period. Customers determine how long the data is stored in Sapper. Data is automatically purged after retention period.
Any customer data chosen to be stored in Sapper is AES 256-bit CBC encrypted using customer supplied encryption key. Our developers cannot access customer data.
Additionally, Sapper provides switches to disallow exporting of data to any file format such as CSV, Excel or PDF.
Sapper masks sensitive data throughout the application. Customer key is required to view sensitive data.
Clients login to Sapper using a password which is known only to them. Password length, complexity and expiration standards are enforced. They can be configured for increased complexity if needed. Passwords are not stored; instead, as is standard practice, only a secure hash of the password is stored in the database. Because the hash is relatively expensive to compute, and because a “salting” method is used, brute-force guessing attempts are relatively ineffective, and password reverse-engineering is difficult even if the hash value were to be obtained by a malicious party.
Users can further protect their login information by using Two Factor Authentication provided by Sapper.
Sapper supports integration with 3rd party SAML compliant SSO systems. This allows an enterprise to manage access to Sapper as well as other enterprise applications and apply custom authentication schemes and policies.
Sapper supports automatic session logout after a period of time. Enterprises can set the appropriate timeout period according to their security needs.
When Sapper workflows connect to remote systems using user-supplied credentials, where possible this is done using OAuth2, and in those cases, no credentials need to be stored in the Sapper system. However, if a remote system requires credentials to be stored, they are encrypted using a 256-bit key.
Application Development and Testing
Sapper has a comprehensive software development lifecycle process that incorporates security and privacy considerations. Design and code reviews, as well as unit and integration testing, are part of the process.
Development staff receive regular training on Secure Coding Practices, including avoidance of the OWASP Top Ten Web application vulnerabilities. Secure coding practices are guaranteed by regular static code analysis using Sonarqube.
Sapper undergoes an annual penetration test of the product by a qualified third party. In addition, regular internal vulnerability scans are conducted. Sapper follows an aggressive timeline for resolution of any critical, high, medium or low vulnerabilities identified.
Sapper has deployed a variety of security and monitoring tools for its production systems.
While we don’t anticipate there ever being a breach of our systems, Sapper has put in place a Security Incident Response Plan, which details roles, responsibilities and procedures in case of an actual or suspected security incident.
Sapper is progressing towards SOC 2 report, and plans to be SOC 2 Type 1 report by end of year 2020 and SOC 2 Type 2 report by mid-2021.
All employees are subject to background checks that cover education, employment and criminal history. Employment at Sapper requires written acknowledgement by employees of their roles and responsibilities with respect to protecting user data and privacy.
Sapper maintains an information security training program that is mandatory for all employees.
Knowledgeable full-time security personnel are on staff.