Since we're attracting larger clients today than a year ago, with more complex needs for security, we wanted to write some words about our platform's security to ease our clients' minds.
Magic Cloud is the name of our platform. Magic is what allows us to deliver our AI solutions - So writing about our technology's security basically implies writing about Magic Cloud's security.
1. Cloudlets
We serve our AI platform as "cloudlets". A cloudlet is basically a Kubernetes POD built from a Docker image. This implies there are no shared file system or configurations. Each of our clients have their own file system, their own set of configuration options, and their own private database. Magic Cloud is not a multi tenant system, but a Docker container.
This makes it more difficult to deploy and manage, but increases security by several orders of magnitudes. It's not even possible in theory to have one client accessing data from another client for instance.
When we build these Docker images, we also create a unique user that the process runs within, which does not have write access to anything but the files and folders it should be able to write to. So having a security breach corrupting the underlying operating system is theoretically impossible.
We are also scanning these images automatically as an integrated part of our build process using automated tools such as Snyk.
In addition we're running our core server infrastructure on Linux, and we're always keeping the operating systems of our cloudlets updated, with recent versions, to avoid operating system related security issues.
On top of this, we're using a CDN network, and never exposing the physical IP address of our Kubernetes cluster publicly, encrypting the information sent from our CDN network to our Kubernetes controller plane, eliminating yet again an entire axiom of security related issues.
2. Database
In addition, the core database Magic runs on is not exposed to the internet at all. It's an SQLite-based database, only accessible from the file system within the cloudlet itself. This eliminates an entire axiom of security issues, resulting in that it's impossible for un-authorised users to get raw access to the database itself.
In addition we persist passwords into the database using BlowFish slow hashing, with per-record based salts, making it matemathically impossible to reverse engineer your password, even if some adversary gained physical access to the raw database files itself. BlowFish password hashing is the same technique that the NSA and the CIA uses to store passwords may I add.
SQL injection attacks is also effectively eliminated by using SQL parameters, making SQL injection attacks literally impossible.
3. Static code analysis and unit testing
Statically analysing code can eliminate an entire axiom of security related issues. Magic contains more than 1,000 unit tests, measuring test coverage, in addition to scanning the codebase for security issues during builds. Most projects in Magic have more than 98% unit test coverage. The industry requirement is 80%. We're outperformning the industry requirement by almost one order of magnitude.
For the record, less than 2% of all software is even capable of meeting the industry minimum requirement. We are outperforming the industry minimum requirement by one order of magnitude!
In addition, not one single method in Magic has a cognitive complexity above what's considered the maximum threshold required to make it easy to maintain. Cognitive complexity is a huge source for security issues, because once the code becomes difficult to understand, security issues becomes difficult to see.
4. Updating libraries
All 3rd party libraries we're using in Magic are kept updated. GitHub helps us here, by giving us warnings about updates we have to apply for security reasons - But we always makes sure we're using the latest security patches of any libraries we're using in Magic. In addition we're super conservative with what 3rd party libraries we pull into its core, and we are analysing all libraries for security related issues before we consider using them - And only if the library is found to be of super high quality applying all security related best practices we consider using these in the core of Magic.
For instance, Magic is using the latest stable release of .Net 8, and once .Net 9 becomes mature, we'll update the entire codebase to .Net 9. By using .Net we're also eliminating an entire axiom of security related issues, such as buffer overflow or buffer overrun. 98% of every single security breach we've seen in Windows and Linux the last 20 years are based upon buffer overflow issues. Because of the way .Net is built, experiencing a buffer overflow in .Net applications is literally impossible.
5. The best security I've seen
This is going to sound like bragging, but it is the truth. I've worked as an enterprise software developer for 25 years of my life, and Magic is the by far most secure system I have ever worked with.
The reason is quite simple, I'm its sole developer. Security related issues often sneaks into a system as a consequence of human software developers misunderstanding parts of the code base, and therefore unwillingly adds security issues, simply because of a lack of understanding how the existing code works. An entire axiom of security related issues originates from junior software developers. I've got 25 years of professional experience, and 42 years of software development experience in total - So I'm obviously not a junior software developer.
Being the sole software developer on Magic, this entire axiom of security related issues simply vanishes, and becomes 100% irrelevant for us.
I have worked on finance related software projects responsible for moving billions of dollars annually, in addition to medical related software where security issues could literally be the difference between life and death. Still, Magic is the by far most secure system I have ever worked with in my entire life.
Magic's codebase is from 2019, and its core foundation was invented in 2013. This implies we've had more than 10 years to stabilise and mature our technology.
6. We're NOT ISO compliant
We are not ISO compliant, simply because there's no ISO standard in existence today, with requirements high enough for our platform - So we've not even bothered with ISO standardising our security. Security related ISO standards are often also counter productive for security. A great example of this is how they force you to install password managers, sometimes extremely insecure password managers may I add, adding a whole new axiom of potential things that can go wrong, effectively increasing your attack surface - Instead of reducing it.
We've evaluated all security related ISO standards, and they're simply not secure enough for us!
A great example of counter productive security measures can be illustrated by how a security firm contacted us about a security issue they claimed having found in our AI chatbot technology a couple of months ago. We analysed their report, reproduced the issue, and after careful examination of their findings, we concluded with that the only thing they had achieved was to literally hack their own browser - And that there was no way their alleged security issue could in any ways affect other users besides themselves.
Since I didn't want to pay this security firm for having "hacked their own browser", I checked out their website, and I found 3 security issues I reported back to them, 1 of which was severe.
In addition there's one person in the world having access to our Kubernetes infrastructure, and that person is me - Period! This is because when it comes to security, I'm the most paranoid person you've ever met - And when it comes to security, paranoia is a good thing!
On top of that, I have never physically logged into neither our Kubernetes cluster, nor our cloud hosting provider's admin dashboard, using anything but *Nix based operating systems, making spearphish attacks based upon keyloggers almost impossible. We also have 2FA turned on in every single part of our Kubernetes cluster infrastructure, in addition to on our codebase - Making it impossible to modify our code and inject malicious code without physically stealing my phone.
7. Disclaimer
So far (knock on wood), we've not have a single security related issue at AINIRO, and we are constantly doing everything we can to avoid breaches.
There are of course no guarantees when it comes to software security, because of the complexity of the domain - But we've applied dozens of layers of security, making security breaches highly unlikely.
If you are still not convinced, we allow for enterprise customers to study our codebase, assuming they're willing to pay for access to it, and sign the relevant IP contracts to avoid misuse or IP theft.
If you do, I'm 100% sure of that you'll see just as we do, that this is literally the most secure software system you've ever seen!
When that's said, please for the love of God use passwords with high amount of entropy that you don't use any other places as you create your root users in your cloudlet. 99% of every single intrusion ever seen in this world was because some human being chose to use "admin123" as his password.
FYI, not even Facebook is hashing your password, implying there are 20,000 software developers working for Facebook that already knows your Facebook password - Implying if you're reusing this password on your cloudlet, any schmuck working for Facebook can access your cloudlet. Yes, true story, it was revealed almost a decade ago by a leak, and there are few reasons to believe they've fixed these issues since!
The latter seems to be a general pattern in our vertical, where almost none of the big social media companies are capable of avoiding storing your passwords in clear text, implying one breach at Facebook, and malicious hackers can access every single system you've ever used that same password on.
With Magic you can even use passphrases, entire sentences, increasing the entropy from 72 to the power of 8 to 12 to 150,000 to the power of 25 to 50, allowing you to use entire sentences as your password. If you do, the amount of energy required to brute force your password would exceed the amount of energy required to boil all the H2O (water) in the entire known universe!
And secure your client for the love of God. No amount of security features in Magic is ever going to save you from a keylogger you unwillingly downloaded because of "clicking that love letter some random girl on the internet sent you a couple of days ago."
99.99% of every single security breach originates from human failure and human flaws, and there's nothing we can do here except warning you about it, and teaching you how to avoid such human failures. However ...
I can guarantee you that Magic is probably the most secure system you have ever used!
And ...
I'm willing to bet 100 bucks on that if the CIA currently have an "OpenAI management system" in use, it's with 99% certainty Magic! If it's not, they're doing something wrong!
Top comments (0)