Going from a network dependant API to a completely offline service
At SafeTalpa, where we’re helping merchants maintain PCI compliance, we used to have our algorithms packed up in an API which would be available in all mayor server-side programming languages. However, we found several problems with this approach.
In order to mitigate all this problem, we decided to make a Linux service that would work on any Linux server (starting with Ubuntu 18.04.2). After this we had an insight regarding our newest approach: Many of our users’ infrastructure where they store sensitive information will be in a secure zone where there is no external network access, and with this we realized that many of the information we wanted to analyze and many of the results that we would gather and store in our own infrastructure implied a high level of trust from our user. The information we would be gathering would contain our user’s client information as well as the vulnerabilities that our clients have, which is very sensitive information. We needed to find a way where Safetalpa analyses the information but doesn’t own it. In order to solve this, we decided to make all our software run offline inside the user’s infrastructure; this implied a complete rework on where we stored the information and how we present it to the user.
In order to run as a Linux service our first decision to make was whether to analyze the whole cluster or the container in which Safetalpa would run. We decided to analyze the whole cluster as it would give our software the “big picture” of the information on the real security problems that the infrastructure has. In order to achieve this, the decision made was to pack and deliver our software using Kubernetes as our software will be delivered as a container.
Initially, Safetalpa will be structured using three k8s pods. All of this, running locally on the user infrastructure. The first pod will contain the code of our algorithms which analyze and find some non-PCI-compliant settings. This information is sent to the second pod which will include a NoSQL database using Elasticsearch, in this database the results of the analysis and the PCI important logs will be stored. The second pod will connect with the third one, which will contain the code of our dashboard. This dashboard will be the graphical representation of the analysis for the user to see and take the necessary actions. This will allow us to run every analysis and present it to the user, without Safetalpa actually managing any of the sensitive information.
Once this infrastructure was decided we had a business problem: How will we charge a subscription to our service when our service is offline? We decided to use a pubic and private key schema with a hidden message. First, each download of our service will contain a message which will contain the information of the starting a finishing date of the subscription as well as some necessary information for Safetalpa to run smoothly, all our containers will be seeing this message daily. If the current date is out of the range of dates, then the containers won't work. This message is encrypted with a private key, and the public key for opening it will be delivered to the user once he has paid for the subscription. The public key will decrypt the message and allow Safetalpa to start working within the time frame of the subscription.
All of this implied a huge change in our product, but we are confident that is in our users’ best interest and is a very positive change regardless of the big tech challenge it implied.
As a final line, always remember: “Don’t stop coding”.
If you would like to learn more about our startup journey or just cope emotionally with us, please follow us on Twitter.
If you want to learn how your company can maintain PCI compliance in a cost-effective way, please email us at sales@safetalpa.com
If you’re an online payments/cybersecurity expert and would like to give us some feedback, please email us at info@safetalpa.com
