How to Build Secure Voice Applications for Your Brand

June 28, 2018


Smart speakers continue to rapidly become more integrated into our daily lives. There are now 50 million+ people globally activated on Amazon Alexa and Google Assistant-enabled devices, and thousands more adding devices to their homes every day. Besides driving user engagement, e
nsuring security for voice applications is critical for brands, so it is important to understand the key security procedures and privacy policies when choosing a software platform.

Protecting the security and privacy of our customers’ data is a top priority at PullString. Our platform, PullString Converse, provides a visual authoring environment for creating engaging voice applications that can be deployed to popular platforms like Amazon Alexa. As an enterprise-level solution, it’s critical for us to provide a secure product where customers can be confident that their data is stored safely and protected from unauthorized access. We take this responsibility very seriously. This article describes the various ways we achieve this goal. 

Secure Web Authoring

PullString Converse is a responsive web application where our customers can sign in to create and manage their voice apps. We enforce HTTPS communications for all pages on our website to minimize “man-in-the-middle” style attacks, and we employ HTTP Strict Transport Security (HSTS) and Cross-Origin Resource Sharing (CORS) headers for additional security. We also use industry-standard 2048-bit RSA certificates signed with SHA256 for all our production servers.

In terms of the customer data that we store in our service, these are always stored using “encryption at rest”, meaning that the data are encrypted while stored on disk in addition to while it is being transported back and forth to our servers. We also perform regular database backups across different geographic locations to ensure that our customers’ data are recoverable in the event of a catastrophic event.

A common hacker attack vector is to focus on breaking user passwords. PullString's password requirements match or exceed those of most online services, specifically:

  • We require all passwords to contain 8 or more characters and to include a mixture of uppercase and lowercase characters in addition to at least one number and one special symbol.
  • We disallow the use of commonly-used passwords.
  • We rate limit account sign ins to mitigate brute force password attacks.
  • We log all sign in attempts to be able to provide audit trails.

Finally, all passwords are stored using a secure one-way salted hash, i.e., never as plain text.

Role-Based Permissions

Within the PullString Converse application itself, we provide support for teams collaborating together, because we believe that the best voice apps are produced by teams of creative and technical professionals working together. This includes support for multiple users within an account that can have different roles, each with different access and permission levels.

For example, an Admin can see all users and perform all actions; a Program Manager can own one or more projects and has full access to actions within those specific projects; and an Author can edit content for voice apps they are invited to, but they cannot create or delete projects and they cannot deploy content to production users. These account management features give our customers fine-grained control over the access and capabilities that their team members have within our product.

Run-Time Security

In addition to providing a secure web-based authoring environment, PullString manages the run-time conversations for our customers’ end users who interact with devices like the Amazon Echo. It’s worth noting that Amazon’s architecture completely hides PullString’s runtime infrastructure from end users. That is, an end user who talks to an Echo device will have their voice input processed by Amazon. Amazon's servers will then contact PullString's servers so that we can direct them on how best to respond and then Amazon returns that response to the end user. In other words, end users are never able to see or intercept traffic to our servers when interacting with devices like the Echo.

Independent of this architectural level of security, we are committed to providing a secure runtime service to run our customers’ voice apps. Our infrastructure is built on top of Amazon Web Services (AWS), which maintains compliance with leading security standards like SOC2, SOC3, and ISO 27001. We also take full advantage of the many great features of AWS to increase the security of our service, including the use firewalls, security groups, and IP address whitelisting to prevent unauthorized access to servers and databases.

While no production services are run out of PullString’s offices, it is still important that we employ onsite security mechanisms so that a breach of our physical location does not affect customer data or experiences. As part of this, we follow industry best practices around the use of commercial password management services to ensure that our internal services are protected by programmatically-generated passwords containing 20 or more random characters. And we use identity access management systems to ensure that only trained employees with a direct business need have access to critical services.

Security As A Mindset

Security is not a feature that you deliver once and then you’re done. It requires continual and prioritized attention as new features or new infrastructure configurations change the surface area of the product. There are several activities that we perform at PullString to ensure that security is always at the forefront of our minds. One part of this is having delineated security reviews as part of our regular software release process. We also perform regular external security audits, where we engage an external security contractor to perform independent penetration testing of our platform and make sure that we follow up on any significant issues.

Finally, we run a public security bug bounty program, where we invite external security researchers to find potential vulnerabilities in our service and incentivize them to do so by paying them for each legitimate issue that they find. The combination of all these policies means that we have many eyes continually focused on the security of the PullString service and that we are constantly working to ensure that we are providing our customers with a highly secure and safe product. This is all further backed by our commercial-grade SLA.

To learn more about how we protect the security and privacy of our customers’ data, visit our security webpage. Developers can find security best practices for Amazon Alexa here.

Written by Martin Reddy

Martin co-founded PullString and manages the company's engineering effort. He holds a Ph.D. in Computer Science, has published more than 40 peer-reviewed articles, authored half a dozen patents, and written two books, including "API Design for C++."

Recent Posts