Signing the CISA Secure by Design Pledge

Today, I’m thrilled to announce that Tines has formally signed CISA’s Secure by Design pledge. Since our founding, we have been guided by the fundamental belief that secure software is security software, and that our customers shouldn’t need to make a tradeoff between adding valuable automation capabilities or reducing their attack surface.

Because secure software design is in our DNA, we believe that we already meet or exceed many of the goals outlined in the pledge. That said, we know security is a journey, not a destination. The pledge includes a set of seven principles aimed at ensuring software design is secure at a foundational level. This blog post outlines both our existing investments in those Secure by Design principles, as well as where we plan to make additional investments over the upcoming year.

1. Multi-factor authentication (MFA) 

Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.

At Tines, we don’t believe in the “SSO tax” - that is, the idea that Single Sign-On authentication should only be made available at higher paid subscription tiers. All paid Tines plans include SSO, allowing our customers to configure their own preferred MFA mechanisms and step-up authentication logic. 

In addition, free Community Edition Tines users authenticate via passwordless magic links or their Google or Microsoft account, ensuring that no passwords are ever stored in the Tines platform.

While these mechanisms allow customers to set and use strong MFA across all Tines products, it is challenging to enforce the use of strong MFA due to limitations in how (and whether) SSO providers expose this information to client applications such as Tines. We encourage these identity providers to take advantage of standardized SAML assertions and OIDC claims in this regard.

2. Default passwords 

Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.

Thanks to our use of universal SSO and passwordless magic links, no Tines cloud customer will ever set a password within the Tines platform, much less a default one. For self-hosted Tines customers, the initial platform deployment flow requires the tenant admin to authenticate either via passwordless magic link or via setting their own strong password - no default passwords involved.

3. Reducing entire classes of vulnerability 

Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.

Software simplicity not only allows businesses to ship new features faster; it’s an effective approach for reducing entire classes of vulnerability as well. Because Tines runs as a Ruby on Rails application, our engineers are able to leverage native security mechanisms for preventing issues such as cross-site scripting (XSS) and SQL or OS command injection attacks. 

In addition, Ruby itself has been designated a memory-safe language by the NSA, reducing yet another class of vulnerability.

Still, we know that eliminating vulnerabilities is a moving target. Over the course of the next year, we intend to focus on additional hardening for our container images, since the best way to manage vulnerabilities and CVEs is to avoid running that software in the first place.

4. Security patches 

Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.

Thanks to our robust CI/CD pipelines and automated deployment processes, Tines is able to safely release software updates to our cloud customers multiple times per day. This not only includes new features and functionality but also any security patches that may be available or required. No action is necessary on the customer’s part to have these patches automatically applied to their tenant.

For our self-hosted customers, Tines releases a new version of our platform approximately every two weeks, with patch versions for security issues or significant bug fixes being made available as required. Self-hosted customers automatically get access to all software updates for the duration of their contract with Tines.

5. Vulnerability disclosure policy 

Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP).

Tines maintains a documented vulnerability disclosure policy on its Security page, with the underlying reporting and tracking of disclosed vulnerabilities being powered by BugCrowd. We recognize the value of good-faith security research and want to encourage responsible vulnerability disclosure practices. 

That said, we believe we can make some improvements here. For example, we can make it clearer that we don’t intend to pursue legal action against anyone who makes a good faith effort to responsibly disclose a vulnerability to us. We also intend to publish a security.txt file which will make it easier for researchers to find our preferred mechanisms for responsible disclosure.

6. CVEs 

Within one year of signing the pledge, demonstrate transparency in vulnerability reporting.

For SaaS vendors, the question of whether to issue a CVE (vs. providing some other kind of security bulletin) has historically not been as clear-cut as it has been for customer-installable software. Indeed, until a few years ago, the definition of a “vulnerability” under the CVE program implicitly excluded SaaS. 

Tines is committed to being transparent with its customers about security issues if and when they arise. Over the next year, we intend to develop and implement a strategy for consistently disclosing vulnerability information in both our self-hosted and cloud platforms, using standardized mechanisms like CVEs where appropriate. 

7. Evidence of intrusions 

Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.

Our Audit Log capability automatically and consistently captures a log entry for every operation available in the user interface and API, including enriched actor information and metadata related to the operation carried out. Audit log records can be retrieved via either the admin UI or via API. 

We recognize that for cloud customers in particular, immutable audit logs are frequently the only mechanism available for gathering evidence of potential cybersecurity intrusions. Over the next year, we intend to provide expanded access to audit logs, by adding native integrations for streaming them to a SIEM. 

Conclusion 

As the saying goes, a rising tide lifts all boats. Within security software, when an individual piece of software becomes more secure, so does the entire ecosystem. This is critical to Tines’ success as a workflow and AI orchestration platform, and more importantly, the success of our customers. 

Over the next year, we will continue to provide updates on our progress as stated above. We also look forward to championing the Secure by Design Pledge within the industry.