DEV Community: Nathan Loding

Simpler way to secure data with Ruby and Basis Theory

Nathan Loding — Wed, 18 May 2022 19:03:24 +0000

This guest post walks through a community-built Ruby Gem that helps developers quickly secure and use their data with Basis Theory and the new Rails 7.0 upgrade.

Ruby on Rails built its reputation on its ease of use and simplicity. As an engineer, I look for ways to remove the complexity of encrypting and securing data within my projects. Recently, I’ve been using Basis Theory’s tokenization API to protect business-critical data without worrying if I’m missing some critical part of the encryption process.

I use Basis Theory’s tokenization platform and compliant environment to quickly and compliantly secure and use sensitive data for my projects. By using its tokens, serverless functions, and SDKs, I have full control over their sensitive data without incurring the costs, delays, and risks of securing and maintaining it myself. (You can also get to production without a credit card).

Want to jump straight into the gem? Check out the Github repository or RubyGem.

What is Basis Theory and the basis_theory gem?

This gem eliminates the need to worry about building additional Key Management Services (KMS) infrastructure while securing your data in Basis Theory’s PCI Level 1 compliant vault.

Why is the basis_theory gem important?

While native encryption helps everyday developers quickly secure their data within an application, a scaled implementation using public libraries will still require detailed knowledge of Key Management and infrastructure needs.

How does the basis_theory gem work?

The example below shows how to start with Basis Theory.

Install the package.

gem install basis_theory

Create a new Basis Theory client with your Basis Theory API Key

 client = BasisTheory::Client.new(api_key: 'YOUR_API_KEY')

Protect the data by creating a new token

 token = client.tokens.create(data: 'some_data_to_encrypt') token.id # => '467ca27f-bb2a-4d09-9e0e-8f8a69e7bbac'

‍‍4. That’s it! You’re now ready to store the ids in your database and can retrieve the raw values whenever you need to use them by using the gem’s find method

 token = client.tokens.create(data: 'some_data_to_encrypt') token.id # => '467ca27f-bb2a-4d09-9e0e-8f8a69e7bbac'

What data am I encrypting with the the basis_theory gem?

The gem takes all of the hard work of setting up Ruby encryption libraries. This allows you to generate and protect your encryption keys, or build out your own KMS. I’m using it for Government IDs, Social Security Numbers, and Tax ID Numbers. Additionally, I could also see the need to encrypt confidential or proprietary information, like CAD designs, pricing, and inventory, that, if leaked, could have a profound impact on my clients.

What is next for the basis_theory gem?

There are quite a few features within Basis Theory that would be great to expose through the gem, like:

Add Basis Theory’s Search on tokens

The Basis Theory API allows for searching the underlying encrypted data without the need to decrypt that data and/or have the data touch your systems. This is a massive improvement over the built-in native encryption offered by Rails (as you’d need to turn on deterministic encryption which is less secure). An example of the feature might be:

client.tokens.create(type: 'social_security_number', data: '444-44-5555')
client.tokens.create(type: 'social_security_number', data: '444-44-5522')

client.tokens.search(data: '5555') // returns only the first token
client.tokens.search(data: '444445522') // returns the second token

Basis Theory EncryptableRecord for Encryption

Native Rails encryption has come a long way and provides a default EncryptableRecord which is the foundation for encrypting data within ActiveRecord. The idea would be to enable a new EncryptableRecord to be exposed. This would allow Basis Theory to be used as the underlying datastore and store a tokenId in the database:

// Ability to override the Provider
class Article < ApplicationRecord
  encrypts :title, :provider = BasisTheory
end

//Ability to easily configure tokenization on ActiveRecord properties
class Article < ApplicationRecord
  tokenizes :title
end

What would you like to see?

Feel free to submit a GitHub issue for any ideas you may have for the next steps on the gem.

About the author

‍Scott Olsen is a Software Engineer at Doximity, an online networking service for medical professionals. He has spent the majority of his career building and investing in the Rails community. You can find Scott on Twitter.

Why is Data Security a Developer Service Problem?

Nathan Loding — Thu, 12 May 2022 20:38:09 +0000

In 2011, Gabe Newell described software piracy “as a service problem.” His comment implied that until there was a better experience from a legitimate service, consumers would continue to engage in the illegitimate offerings—no matter how bad it was for the overall economy.

We interviewed over a hundred developers on data security and reflected on our own experiences at Twilio, Klarna, and Dwolla in developing the Basis Theory platform. Like Newell, we found that the service and, more importantly, the experience provided by that service greatly influenced how well (or poorly) developers and organizations protected and used their most valuable data.

We had a hunch that if we could abstract sensitive data and their compliance, security, and operational requirements, we could help developers fast track compliance. Last August, we launched our beta. Since then, the market's response has been incredible.

We’re not only excited to announce the general availability of Basis Theory, but to share with you the insights and decisions that have guided us here today and are helping us think about tomorrow.

So, why is data security a developer service problem?

When talking to developers three trends tend to emerge:

Securing sensitive data is hard
Using sensitive data is hard
Managing sensitive data is hard

Why is securing sensitive data hard?

Observation #1: Compliance competes for resources, priorities, and timelines. Developers are responsible for ensuring systems and data usage meet existing policies and controls. Unfortunately, doing this correctly often comes with a cost that’s not always supported by the appropriate personnel, focus, or deadlines.

Observation #2: Security isn’t static. Encryption libraries offer developers a great, lightweight, near-term solution. However, scaling this approach to encryption while still meeting the emerging security threats often becomes a continuous and resource-intensive challenge for organizations.

Observation #3: Lots of early decisions with little certainty. Developers face many data security decisions even before the first line of code is written. These questions are highly contextual and, with no straightforward answers, can become the source of anxiety and analysis paralysis. To compound matters, wrong answers can create security risks, maintenance costs, and limitations on future solutions.

Why is using sensitive data hard?

Observation #1: Compliance isn’t black and white. Many believe compliance is binary, but policies and controls rarely account for the contextual factors developers face when writing code. Prescriptive requirements suddenly look like well-meaning suggestions, forcing developers to piece together who, what, when, where, why, and how a particular data type can be used.

Observation #2: Securing data locks up its value. Storing data inside encrypted ciphertext or behind firewalls with access policies protects but also marginalizes its value. This duality between security and utility creates constant challenges for developers and organizations alike.

Why is managing sensitive data hard?

Observation #1: Data governance is ambiguous and decentralized. Decentralized and inconsistent implementations of authorization and access controls result in bespoke solutions for the same problem across multiple systems. In addition, understanding and implementing new access policies in these environments generate complexity and cognitive overhead.

Observation #2: Manual security management can be terrifying. Manually managing systems and controls exposes organizations to human error and limits the number of engineers capable of contributing and reviewing changes. This is especially risky for those systems and controls that handle sensitive data—where missteps can result in irreparable damages to an organization.

Observation #3: Auditing of data access is inconsistent when it exists. Auditing individual access across systems requires engineers to spend valuable time scouring logs and policies. In addition, most logging in place is typically capturing system activity, transactions, and errors—not necessarily user or system behavior. This proves challenging for teams trying to satisfy compliance requirements.

Why [not] Basis Theory?

Our interviews and experiences established Basis Theory’s problem-set, but they didn’t set the bar for the user experience we needed to create for developers. To guide future decisions, we began asking a simple question—one that was both aspirational and practical. We came up with:

“Why wouldn’t you secure all data?,” which we later simplified to, “Why not Basis Theory?”

Over the last year, we focused on simplifying and abstracting the challenges we captured from developers.

Making it simpler to secure your sensitive data

Compliant environments. Complexity is accommodating the nuances of every single compliance and security requirement. By extending our PCI Level 1, SOC 2, and HIPAA compliant environment to developers, we abstract the compliance burdens faced when trying to store nearly every sensitive data type. Tenants, which allow developers to segment their data, also inherit these benefits and can be freely spun up in seconds.

Providing static tokens. Original values are encrypted and stored within a developer’s Basis Theory environment. In exchange, we pass back Tokens, or undecipherable aliases that reference the original value, for developers to use within their code. This allows sensitive data to be stored in an encrypted state for as long as possible.

Encryption management. Abstracting the complexities of encrypting, managing, and rotating keys were high on our list, but not just for the developer experience: When coupled with tokens, the approach allows Basis Theory to update encryption algorithms over time without disrupting developers’ systems.

Making it simpler to use your sensitive data

Tokens provide utility and security. Tokens protect data by keeping the original raw values encrypted at rest. In addition, a Token’s attributes—like user-defined metadata, fingerprinting, and custom masking—make them usable and searchable, allowing developers to reveal all or partial raw values, recognize token contents, create associations, and query their parameters in milliseconds.

Tools to interact with your data. Developers already know how to write code to solve problems. Reactors provide a secure, compliant environment to execute code against an organization’s sensitive data—without exposing its systems to the underlying raw value. Similarly, our Proxy solution allows you to use your existing HTTP client to detokenize data in-flight and forward it to the desired destination.

Making it simpler to manage your sensitive data

Granular access controls and permissioning. Assigning classifications and NIST impact levels to your data allows developers to tailor access, visibility, and functionality to the underlying data. Tenants provide an additional control layer, allowing developers to segment data by the environment, customer, use case, or business unit.

Enable automation. 100% of the engineers we interviewed want to automate their jobs' mundane and error-prone responsibilities, so we ensured that engineers could manage their entire experience through our API. As a bonus, we also built a Terraform Provider.

Centralized operations. This one is pretty straightforward. Engineering, security, and support teams can access logs, search their data, debug, and manage user access, all via the Web Portal or the API.

Last thing

We have a long journey to helping all developers secure their data, but you can get started today. Check out our dev docs, visit our GitHub, or take a few seconds to spin up your own PCI-compliant environment by creating a free account (you can get to production without a card on file).

Special thanks to our incredible team and group of investors, Bessemer Venture Partners, Kindred Ventures, Conversion Capital, Offline Ventures, Ludlow Ventures, BoxGroup, and Good Friends!