At Inbenta, we are committed to safeguarding your data and the personal information of your users. Our technology, infrastructure and processes are continuously being monitored and improved with security being the main focus. We are certified by third-party specialists in Information and Cloud security.
Inbenta is compliant with EU General Data Protection Regulation 2016/679 (GDPR), and our US office branch is certified under the Privacy Shield US-UE Agreement.
All data processed at Inbenta is encrypted both in transit and at rest.
Inbenta has a partnership with Ackcent Cybersecurity, in order to perform scheduled product and code audits, security audits and penetration testing, and to handle all SOC/SIEM, Intrusion Detection and Prevention.
Cloud & network security
|Physical Security||Inbenta runs on top of AWS in various regions. The supporting infrastructure and systems are hosted at AWS facilities; as a result, physical security controls, on-site security and Monitoring of the Datacenters are the responsibility of AWS. Application security and Privacy out of AWS scope and the shared responsability model is handled by Inbenta and covered by being compliant with GDPR, ISO9001, ISO27001 and ISO27017.|
|Dedicated Security Team and SIEM||Our security monitors and alarms (active/passive systems) as well as our external SIEM security partner are fully integrated into our operations, providing 24×7 security and security teams ready to respond to alerts and events.|
|Protection||Our network is protected and isolated by firewalls, NACL (network access control list), secure HTTPS transport over public networks, DMZ monitorization, regular audits, and network Intrusion Detection and/or Prevention technologies (IDS/IPS) which monitor and/or block malicious traffic and network attacks, DDoS active protection and DNS spoofing monitoring.|
|Architecture||Our network security architecture consists of multiple zones. More sensitive systems, like databases, cache and NFS servers, are protected in our most private zones fully isolated. Other systems are housed in mid-private zones like webhook processors in private subnets behind an egress-only NAT. Depending on the zone, additional security monitoring and access controls will apply. DMZs are utilized between the Internet or public subnets (Load Balancers only), and internally between the different zones of trust.|
|Firewalls||Firewall systems are in place to filter unauthorized inbound network traffic from the Internet and deny any type of network connection that is not explicitly authorized. Network address translation (NAT) functionality is utilized to manage internal IP addresses. Administrative access to the firewall is restricted to authorized employees.|
|Network Vulnerability Scanning||Network security active scanning is actively running on all subnets across all regions for quick identification of out-of-compliance or potentially vulnerable systems. Scheduled passive scans are also executed for all internal or private subnets as well as all DMZ or public subnet facing exposed ports (http/https).|
|Third-Party Penetration Tests||In addition to our extensive internal scanning and testing program, each year Inbenta employs third-party partners (Ackcent Cybersecurity) to perform a broad penetration test across the Inbenta private and public Production Networks, as well as perform products audits on all products on a per quarter basis.|
|Security Incident Event Management (SIEM)||Our Security Incident Event Management (SIEM) system gathers extensive logs from important network devices and host systems. The SIEM sends alerts on triggers which notify the Security team based of the correlated events for further investigation and response.|
|Intrusion Detection and Prevention||Application data flow ingress and egress points are monitored with Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS). This is integrated with SIEM and 24/7 operations.|
|DDoS Mitigation||Inbenta uses real time network flow monitoring to inspect incoming traffic in all http entry points such as CDN https terminations, https load balancer listeners and all secure websockets terminations (wss://) in order to perform automated mitigation of most DDoS techniques on layer 7 (WAF), and protect against all known infrastructure (Layer 3 and 4) attacks.|
|Logical Access||Inbenta uses role-based security architecture and requires users of the system to be identified and authenticated prior to the use of any system resources. Production resources and all administrative actions are recorded and stored for at least 2 years with an unmutable checksum in order to prevent audit logs being modified.
All production resources are managed in the asset inventory system and each asset is assigned an owner. Owners are responsible for approving access to the resource and for performing periodic reviews of access by role.
Access to any Inbenta Production administration network or subsystem is restricted by an explicit need-to-know basis as controlled by the ISO27001 and 27017 controls. All is controlled and monitored by our Operations Team with granular and specific roles per employee. Employees accessing the Inbenta Production Network administration are required to use multiple factors of authentication, with both factors having credentials that expire with low TTLs forcing them to be rotated continuosly.
|Security Incident Response||In case of a system alert, events are escalated to our 24/7 teams providing Operations, Network Engineering, and Security coverage. Employees are trained on security incident response processes as controlled in both ISO9001 and 27001.|
|Encryption in Transit||Communications between you and Inbenta servers are encrypted via industry best-practices HTTPS using Transport Layer Security (TLS) protocol over public networks with the latest non-weak cipher suites. Additionally no SSL protocols are allowed. TLS is also supported for encryption of emails. A more detailed specification can be found on the “Transmission Security and integrity” section of this document.|
|Encryption at Rest||All inbenta managed data, disk, filesystems or datastores are encrypted using provider managed key-management-systems (AWS KMS – AWS CMK) using keys managed and maintained by Inbenta and its rotation program. All data is encrypted using the industry-standard AES-256 algorithm and strongest block ciphers. Inside the AWS-KMS service Inbenta uses 2 types of managed keys:
Encryption with Customer-Provided Keys and Encryption with AWS KMS-Managed Keys.
|Availability & continuity|
|Uptime||Inbenta maintains the Status Portal, available for logged in users, which includes system availability details, scheduled maintenance, service incident history, and relevant security events.
The minimum guaranteed Uptime per month/quarter/year can be found at the SLA: https://www.inbenta.com/en/compliance/sla/
|Redundancy||Redundancy is built into the system infrastructure supporting production services to help ensure that there is no single point of failure, including firewalls, routers, and servers. In the event that a primary system fails, the redundant hardware is configured to take its place.
Inbenta employs service clustering and network redundancies to eliminate single points of failure.
|Backups||Customer data is backed up and monitored by operations personnel for completion and exceptions. In the event of an exception, the operations Team performs troubleshooting to identify the root cause and then re- run the backup job immediately, if possible, or otherwise as part of the next scheduled backup job. Backup infrastructure is managed by the cloud provider and does not involve physical media handled by Inbenta personnel. The backup infrastructure resides on long-live datastores behind private networks logically secured from other networks and is AES256 encrypted at rest using the keys management system by the cloud provider (AWS KMS) using Inbenta managed private keys rotated as per scheduled basis.
A scheduled random backup integrity check occurs weekly.
Backups occur, at minimum, every 24 hours for all production data. Depending on the type of the data classification of the backed up storage a different periodicity is specified in 3 tiers: 1) Point in time recovery for critical data, 2) Every 12h for configuration data and 3) Every 24h for less changing and log data.
|Disaster Recovery||Our Disaster Recovery (DR) plan ensures that our services remain available or are easily recoverable in the case of a disaster. This is accomplished through building a robust technical environment, creating Disaster Recovery plans, a provider-redundant disaster recovery plan, and the set up of a low value RTO and RPO. Our policy and protocols on how and when to test and perform Disaster Recovery simulations and integrity validations exist in place as required by ISO27001/27017.|
|Secure development (SDLC)|
|Security Training||At least twice annually, engineers and developers participate in secure code training and security by design developing best practices, common attack vectors, and Inbenta security controls. This training is provided by internal and external training programs and training suites.|
|OWASP Security Controls||Inbenta Support utilizes all OWASP top security known rules. These include inherent controls that reduce our exposure to Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), and SQL Injection (SQLi), among others. Both in static code analysis and dynamic analysis, as well as realtime-active WAF (web application firewall) rules in front of any HTTP listerner.|
|QA||Our QA department reviews and tests our code base. Several manual and automated tests are performed and integrated with the CI/CD pipelines in order to deploy only tested and secure code. Our QA team participates actively in the end-application security as well as the development process in the release pipeline/flow.|
|Separate Environments||Testing, development and staging environments for product development are separated physically and logically from the Production environment via network isolation, firewalls and NACL. No actual production Data is used in the development or test environment, mock and random data may be generated in order to simulate high data volumes.|
|Internal Dynamic Vulnerability Scanning||We employ a number of third-party, qualified security tools to continuously dynamically scan our applications against the OWASP rules. Additionally all http handlers have an active WAF blocking all known owasp and known top rules in realtime.|
|External Dynamic Vulnerability Scanning||Inbenta uses an external security partner for the external SOC-SIEM team.
The third-party partner uses industry standard scanning technologies and a formal methodology specified by Inbenta (all OWASP rules, and many more).
|Static Code Analysis||The source code repositories for Inbenta Applications, for both our webGUI and Product APIs, are continuously scanned in the testing and review stages in the CI/CD (continous integration) Pipelines and Flow, and they are integrated with all QA and release flows blocking any release or deployment of non-compliant or sub-standard code. Additionally, scheduled scans are triggered by our integrated static analysis tooling.|
|Security Penetration Testing||In addition to our extensive internal scanning and testing program, each quarter Inbenta employs third-party security experts partners (external SOC-SIEM and scheduled pentests and audits) to perform detailed penetration tests and dynamoc code analysis on different applications within our family of products.|
Product security features
|Authentication Options||For all webGUI applications, we offer Inbenta account sign-in with 2FA or custom SSO (IdP).
For Product APIs and/or client integrations (JS SDK), we offer an authentication flow with API keys, secrets/tokens (and domain keys for JS SDK) based on JWT (JSON Web Token) to athenticate and authorize all API calls and actions with the backend.
|Single sign-on (SSO)||Single sign-on (SSO) allows you to authenticate users in your own systems without requiring them to enter additional login credentials for your Inbenta user webWUI and instances.
Security Assertion Markup Language (SAML) is supported.
You can integrate your SSO with Inbenta, since it works as an SP (Service provider) for SAMLv2.
|Password Policy||Passwords can only be reset by the end user with an active email address (username are the same email address). A temporary reset password URL can be generated by the end user in the login page. Password policies are enforcing the latest best known minimum requirements and additional anti-bot detection measures are enabled on all user/password management screens. Admins may also configure a password rotation policy per user.|
|Two-factor authentication (2FA)||If you are using Inbenta sign-in on your Inbenta Support instance, you can turn on 2-factor authentication (2FA) for agents and admins, including apps like Authy and Google Authenticator for generating passcodes OOTP.
2FA provides another layer of security to your Inbenta account, making it more challenging for someone else to sign in as you. If you are using your own SSO IdP (Identity provider) to force your users to use 2FA, you can integrate your SSO with Inbenta, since it works as an SP (Service provider) for SAMLv2.
|Secure Credential Storage||Inbenta follows secure credential storage best practices by never storing passwords in human readable format, and only after a secure, salted, one-way hash over databases filesystem or no-SQL plaforms with encryption at rest and all in-transit operations to the backend.|
SAML SP (Service provider) authentication is also supported for the SSO frontend of all webGUI login access different from the APIs (application). Learn more about API security and enpoint terminations at https://developers.inbenta.io/
|Additional product security features|
|Access Privileges & Roles||Access to data and products within Inbenta Backstage and CM/Chat is governed by access rights, and can be configured to define granular access privileges. Inbenta has various permission levels for users (owner, admin, agent, end-user, etc.) and a per group roles granularity. Access to data for the API/SDK is governed by API keys, tokens and secrets as well as many Identification headers in both tiers for authentication and authorization.|
|Product High Availability and access||Some Authorization endpoints and URLs are accessed via a CDN (content delivery network) in order to guarantee a low latency and high availability to boost content delivery based on the geographic locations of the end user. Additionally a regional or latency-based DNS routing for the SDK integrations can be configured as described in: https://developers.inbenta.io/general/authorization/regions-and-endpoints|
|Private Attachments||In Inbenta CM, by default all instances are sandboxed and secured, all assets and attachments are private and a successful login and permission/role are required in order to view ticket attachments or messages. Additionally, all assets and attachments are stored in an encreypted datastore and are served to agents with a temporary signed URL that becomes unavailable after several minutes.|
|Transmission Security and integrity||All communications with Inbenta servers (back and forth) are encrypted using industry standard HTTPS over public networks. This ensures that all traffic between you and Inbenta is secure during transit. A list of SSL/TLS protocols and cipher suites can be found at: https://developers.inbenta.io/general/authorization/regions-and-endpoints for all API terminations and endpoints. Additionally, for realtime features such as realtime Chat, Inbenta uses secure websockets protocol as a complementary secure and streaming-oriented HTTP alternative.
All SDKs are hosted in a secure and encrypted AES256 datastore and served via a CDN with WAF (cookie/headers check and audit) and all Inbenta SDK integrations use a subresource integrity (sha384 SRI).
|CM outgoing Email Signing (DKIM)||Inbenta CM Support offers DKIM (Domain Keys Identified Mail) for signing outbound emails from Inbenta CM when you have setup an outgoing response email domain on your Inbenta CM instance, and SMTP over SSL/TLS (port 465) and STARTTLS (port 587) for the secure sending protocols.|
|SDK Subresource Integrity||A Subresource Integrity (SRI) check is a security feature that enables browsers to verify that the resources they fetch are delivered without unexpected manipulation. All Inbenta SDKs have this feature available.|
Compliance certifications and memberships
|Auditors||AENOR, the auditor supplier, is part of the IQNet ASSOCIATION network in order to see global coverage all of its certifications (worldwide ISOs):
|ISO 9001:2015||Inbenta is ISO 9001:2015 certified.|
|ISO 27001:2013||Inbenta is ISO 27001:2013 certified.|
|ISO 27017:2014||Inbenta is ISO 27017:2014 certified.|
|TRUSTe® Privacy Certification Programs||We’ve received TRUSTe’s Privacy Seal signifying that our privacy statement and our practices have been reviewed for compliance with the TRUSTe program, viewable on their validation page.|
|U.S.-EU Privacy Shield and U.S.-Swiss Safe Harbor programs||Inbenta has certified compliance with the U.S.-EU Privacy Shield and U.S. – Swiss Safe Harbor programs set forth by the United States Department of Commerce.|
|Industry based compliance|
|Using Inbenta in a PCI Environment||Inbenta is not PCI DSS compliant. Adding a component from a vendor that is not PCI DSS compliant on the credit card checkout page would make the entire payment process not PCI DSS compliant. The alternative is to host that script in the clients’ datacenter, and secure the script using Subresource Integrity.|
Additional security methodologies
|Policies||Inbenta has developed a comprehensive set of security policies covering information security and privacy. These policies are shared with, and made available to, all employees, clients and contractors with access to Inbenta information assets.|
|Training||All employees MUST pass a Security Training which is given upon hire and annually thereafter. All engineers receive annual Secure coding Training, security best practices and security by design patterns training. The Security team provides additional security awareness updates via email, blog posts, and internal wiki, sharing and updating best practices as well as providing periodical presentations as internal events.|
|Confidentiality Agreements||All employees are required to sign Non-Disclosure and Confidentiality agreements.|