This documentation is for Live Forms 9.1. v9.1 is a Cloud Only release. Not for you? Earlier documentation is available too.

COVID-19 Response Info: At frevvo, our top priorities have always been employees and customers. We have taken several steps to promote the well-being of our people, to minimize services disruptions, and to help where we can. Visit our website for updates.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Frevvo Live Forms employs a multi-layered approach to security, access control and application governance.  This broadly includes both application level security features as well as security and policies applied to our cloud based solution.

Live Forms Application Security

Access and Authentication

  • Default security provider with password salt and hashing.

  • Security provider integration with/delegation to third-parties, including SAML/SSO and LDAP/AD for centralized security.

  • Access may be monitored and revoked.

  • Password reset/recovery self-service.

Authorization

Design Time

  • Forms/Flows owned by designer who can administer access. Only the designer/owner may modify the form/flow design.

  • Flow administration may be granted to any other user/role to give full access to audit trail and ability to modify/abort running instances.

  • Access to a flow instance’s audit trail may be granted to all participants or a to a custom set of users/roles.

  • Other users may be granted the publisher role allowing them to administer form/flow access and deploy to production.

  • Only the designer/owner or publisher may deploy the form/flow to production.  Best practice is to have a deployer account on production system that has the publisher role.

End User/Run Time

  • The designer/owner of a form/flow may designate who may use the form/flow with options for:

    • public access (anyone including anonymous users)

    • private access (the designer/owner only)

    • public in tenant (authenticated users logged into tenant only)

    • Custom set of users or roles only.

  • The designer/owner of a form/flow may designate separately who may view individual submissions or may edit individual submissions.  Either of these access lists may contain specific sets of individual users or roles.  Additionally, specific access to individual submissions can be dynamically determined from the form/flow content at the time of submission in order to provide very granular access to specific submissions to specific users/roles.

Encryption

  • All data and app access encrypted via SSL/TLS (encryption in motion).

  • All data at rest is encrypted (AES 256).

  • All passwords salted and hashed.

Accountability

  • All workflow activity logged to an audit trail with access controlled by the designer/owner.

  • All system access/authentication events logged.

Integration

  • Secure integration with third-party cloud services. Support for OAuth tokens and specification of service credentials at the tenant and service level where applicable.

 

Cloud Security

We understand that your data is essential to your business operations and to our own success. We use a multi-layered approach to secure your information, constantly monitoring and improving our processes, services and systems. View our infographic for an overview of frevvo cloud security.

Secure Data Centers

  • Our cloud services are deployed on Amazon Web Services (AWS) infrastructure.
  • AWS provides us first class data centers that are designed and managed in alignment with security best practices and a variety of IT security standards, including SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70), SOC 2, SOC 3, FISMA, DIACAP, FedRAMP, DOD CSM Levels 1-5, PCI DSS Level 1, ISO 27001, ITAR, FIPS 140-2, and MTCS Level 3.
  • All of our servers reside in a number of availability zones in AWS's Northern Virginia region (us-east-1).
  • All customer data, including backups and redundant servers, are located only in the Northern Virginia region. We do not replicate our servers across to other regions either within the United States or internationally.
  • We do not operate in AWS's GovCloud region.

Secure Data Storage

  • All our data at rest, including our databases, backups, read replicas and snapshots, are encrypted before stored.
  • Since we leverage Amazon's Relational Database Service (RDS), our employees have no direct access to the actual database servers, which is fully managed by AWS.

Secure Data Transfers

  • Connection to our environment is done via TLS cryptographic protocols, ensuring that our users have a secure connection from their browsers to our services.
  • Individual user sessions are properly identified and verified on each transaction using a unique token created at login.

Secure Network

  • Our servers are deployed in a secure Virtual Private Cloud (VPC) network divided in a public and a private subnet.
  • All server processing and data storage takes place in private subnets with no direct access to the Internet.
  • We also have strict firewall policies between the public and private subnets, making sure that traffic can flow only in specific directions, to and from specific ports, including strict firewall policies between the application application and database tiers.
  • All traffic flowing out from our VPC goes through NAT instances which protects internal IP addresses from external hosts.
  • We also make sure only a single bastion host can access our internal servers for management purposes. This bastion host has a completely different IP address than our public IP addresses.
  • Our servers receive daily security patches to make sure they remain secure from new exploits. Password access to our servers and remote root logins are both disabled.
  • All AWS API access is audited to a secure write-only storage.

Backups

  • Backups are encrypted and performed daily remaining available for up to 35 days.

Security Policies

  • We centralize all our EC2 security across accounts using standard IAM policies.
  • We implement fine-grained security controls and follow the principle of least privilege.
  • Multi-factor authentication enabled on our master AWS accounts and master credentials are locked away and are not used for routine operational tasks.

 

  • No labels