You should never trust any one person or system with data of significant value. Instead you need at least three parties.
In my last article we talked about the problems associated with modern data security and the principle that we use at Kunai to solve that problem: Trust No 1. You should never trust any one person or system with data of significant value. Instead you need at least three parties.
Ben Franklin’s quote is, “Three may keep a secret, if two are dead.” Probably good advice, but we don't want users to have to kill us to protect secrets, and let's face it: it's just not practical (or legal 😉). In the context of data security, however, the first part of that quote is useful. Three can keep a secret. It’s how our modern HTTPS protocol, which protects every private internet conversation, works.
With the HTTPS protocol we do what amounts to the following: Ask a site that we want to talk privately to, to prove who they are. They give us a certificate that says, cryptographically, who they are. We validate that certificate with a third party identity provider that we trust. After confirmation, we exchange cryptographic secrets with the validated site, then we proceed with a private conversation.
This system of having three separate parties is what we leverage for our security architectures at Kunai. For data protection we extend this with a simple rule suggested in the first article, which is: Don’t keep the keys with the encrypted data. Here’s what this looks like...
In this model, much like the HTTPS model, one cloud provides identity. That cloud is responsible for saying who all the faces are in the diagram, and to what team they belong. Since we don’t want to place blanket trust in our IT department, that includes all the faces in the diagram, not just the users. The individuals that allocate identities are never part of the other teams. Never. Period.
The second cloud stores and manages encryption materials. The individuals controlling that cloud manage the encryption materials and they are also never part of the other teams.
The third cloud stores the data. Again, individuals controlling that cloud manage the encryption materials and they are never part of the other teams.
Finally in order to drive the system, users interact with each of the clouds. They go to the identity cloud to obtain an identity, then they interact with the encryption cloud to get materials to encrypt and decrypt sensitive information. After that, they can safely store the data in the third cloud.
This architecture is very secure. The basic mechanics of it are used for a great many things like secure messaging and password managers, but it has a problem: what happens when you need to process the stored data without the user’s direct involvement? At Kunai we do this with two different security architectures defined by two usage scenarios and one key question: Does the business logic act on the sensitive data?
To simplify securing data, we like to break things down into two usage scenarios for sensitive data. The simple usage scenario is also probably the most common one: You collect some sensitive data that your business logic doesn’t act on. You just pass it along to some other entity. Examples of this: You collect a SSN and you are not the IRS. You collect a Driver’s License Number and you are not the DMV. You collect a credit card number and you are not the issuing bank. In each of these cases you are not acting on the data, you are just collecting it so that you can pass it along to some other business-to-business entity. For this usage scenario, the industry standard architecture that Kunai leverages is called Endpoint Encryption. It’s a straightforward problem with a fair amount of off the shelf ways to implement it and I’ll describe them in the next section.
The second and more complex scenario is that you act on the sensitive data. This is not ideal. There aren’t any solid off the shelf solutions yet for securing this type of data at scale. An example of this are systems that must collect scanned or otherwise unprocessed documents that contain sensitive data, like scanned tax forms. A second example of this would be a system that creates sensitive data, such as a system that tracks blood test results, or sensitive internal chat data, or private judicial records, etc. For this usage scenario the industry standard high security solution is called client side encryption. Every cloud provider gives you the raw API’s needed to implement it, but I have yet to see an off the shelf solution that uses it properly. Since I can’t easily describe an off the shelf solution, I’ll instead describe the architecture Kunai uses to construct custom solutions for this scenario, but I’ll do this in the next article.
Right now, though, let’s get things started by talking about the less complex solution...
The Endpoint Encryption solution is pretty simple and it works as follows: If you want to upload sensitive data to your main data center, encrypt the data before it leaves the client’s control, and store the encryption materials you need to decrypt it somewhere else. The basic security architecture looks like this:
The organization of teams remains the same. The first cloud is still identity. The second cloud is expanded to provide a proxy service that never stores data, but can encrypt it at the end point. This cloud can also decrypt it when it is being passed to an external API. The third cloud is expanded to include the business logic.
If this is what you need, there are many options that fit this security architecture. Which option you pick will determine how much control you have and how much security and compliance scope you have. Let’s talk about a few.
The way that this works is you add something provided by a third party to your client side code that will eventually receive the data. It encrypts the data for you before it leaves the client and heads to your data center. After that your data center receives the encrypted data and it can do whatever it likes with it. When the business logic needs to pass it to the third party, the third party will be able to decrypt it (and then act on it). Depending on what you want to collect and accomplish, there may be some services out there that will allow you to use this architecture. This is how plaid.com works. There are also products from PayPal, Square and others that work this way. It’s how most e-commerce business sites take payments.
The downside is that it’s no longer your application that’s collecting that data. That might be a problem for you, but there’s an easy fix...
What if you want to take sensitive data that you don’t act on and pass it to multiple API’s that will act on it? What if you want full control over your UI/UX? What if the API that you want to communicate with doesn’t provide client side endpoint encryption for your client app? This isn’t uncommon, and there are still off the shelf solutions that can help you. One excellent solution is Very Good Security. It’s not free, but VGS assumes all the risk for you and since you don’t operate it, it’s easy to maintain the three different IT teams because they become the purple team.
Ok, but what if you are a really large company and you don’t want to depend on VGS, or VGS is too expensive. Don’t worry, Kunai has an open source project you can use called KeyStor. It lets you do what VGS does, but you will have to carefully manage it in a data center separate from your main data center. It requires extra work to do this, but it can be done, and we’ve given you a totally free solution that’s easy to deploy, so there’s no excuse for not doing it.
Yep, sometimes that’s important. The simple answer is that if you need to act on the data then do it while it’s still under the end user’s control. This means that you will have to build this business logic into the application that you deliver to the end user. This isn’t always possible or practical. There’s also the possibility that your business logic actually generates sensitive data. Kunai has a solution that solves this use case as well. Things get quite a bit more complicated, and there’s no off the shelf solution that solves this problem properly. In my next article I’ll show you how we do that.
For now, let’s simply revel in the fact that Endpoint Encryption allows our users to follow Ben Franklin’s advice and never tell us their secrets.
Sandeep: Tell me a bit about the early part of your career.
Tom: I spent a decade helping to build start-ups focused on application and database software. This was where I learned how to sell and do business development. I was fortunate to be part of one company going public and another being sold to IBM.
Sandeep: What is something you learned during this time that helped you with consulting?
Tom: I began to appreciate how different customers achieved varying levels of success with the same foundational technology. This made me understand just how critical getting your team and process right can be.
Sandeep: This is something I only came to appreciate years into consulting, especially after the sale of my first consultancy to Capital One.I saw teams in different parts of the company trying to solve challenges like real-time messaging. Same corporate culture, same technology, same internal support mechanisms. Night and day outcomes.
Tom: We saw a lot of the same thing after selling our practice to EMC (sold to Dell in 2015). This is probably the thing I'm most proud of when it comes to the teams I've helped to build: the ability to perform well in a variety of contexts, sometimes in ways that inspires the client team to up their game as well.
Sandeep: Yes. It's particularly cool to see your team succeed in individual ways after an acquisition...consulting skills definitely translate into the corporate environment.
Tom: Totally. We have people who've stayed on at Dell and risen up the ranks, while others took the opportunity to become successful executives at other Fortune 100 companies....or to start their own agencies and startups.
Sandeep: We've both been around a while. My first consulting project was a Y2K thing for Cisco back in 1998. You've been around a little longer than that :). How do you think consulting has changed most during the past five years?
Tom: I think because there is so much infrastructure available now, consulting has become more delivery and outcome-oriented. A better blend of strategic and tactical. Public Cloud has also enabled velocity to increase at a pace unfathomable 5 years ago.
Sandeep: What has stayed the same?
Tom: It's still mostly about people. People who thrive on change and are focused on their personal and professional development. I love that this has not and will not change...it's what I love about consulting.
Sandeep: I know you're adjusting your work style to COVID. You're still a dude who clearly prefers to drive an hour for a socially-distanced hike or outdoor meeting over Zoom any day of the week :) But personal styles aside, what is specifically compelling about a remote agency during the era of COVID?
Tom: Kunai has been remote for years, which gives them an inherent advantage. There is something about the communication and management styles that just works in a way that other organizations are still figuring out.
Sandeep: Yeah, I think what a lot of people fail to realize is that remote work isn't just office work over Zoom. it's an entirely new paradigm. There needs to be an understanding for asynchronous efficiency...and this just takes time and effort to develop. How do you approach remote work and family? What are you learning about separating work and personal time?
Tom: No matter what the form of interaction, Focus. Be present. Quality over quantity. The best weeks are the weeks where I proactively schedule work and personal time. Neil (Kunai's Head of Delivery) shared a great quote with me "With discipline comes freedom." When I am proactively addressing the majority of my professional and personal commitments, I find I earn a little flexibility. A little freedom.
Sandeep: Tell us about a business hero of yours that I may not have heard of before.
Tom: Paul O'Neill is someone you may not know. His work in both the public and the private sector created a profound impact
Sandeep: We are both over forty years old :). How have you learned how to work smarter during the past decade or so? What do you wish you knew about consulting when you were 25 that you know now?
Tom: Consultants want to make lasting change. Lasting change is often not the act of a single person. Today I work much harder bringing others along on the journey.
Sandeep: Last question. What are you doing here? :) Why join a small consulting company this late in your career when you could have a cushy job somewhere else?
Tom: I love a good challenge personally and professionally. When I turned 40, I decided I would run a 10K every Thanksgiving weekend and try to have my finishing time be less than my age. With the exception of one year where I did not run due to a health issue, I have met the goal. I also recently completed the Leadville 100 Mountain Bike race. So, I guess I'm here because I'm a glutton for punishment :) Jokes aside, our customers have a job to do and I intend to put Kunai in a position to execute flawlessly on their behalf. I love committing jointly to audacious goals for our customers and our business.
If FinTech were a planet, what creatures would dot its landscape? What environmental factors would shape life’s evolution? Importantly, what could we learn from it?
Underbanked customers often turn to payday loans and check cashing to meet their financial needs. Now, FinTechs are beating banks to this untapped market.
Banks are racing to transition the majority of customer service to conversational AI. That may be a mistake.