Introduction
Keeping your personal information safe, and maximising data security.
That’s the first thing we think of when we build anything here at MDBX for you, our users, and it takes priority over everything else we do. By design, it’s ingrained into our culture here and we leverage all the tools and experience we have to keep your data safe and secure. It’s important you know that, and so we want to be as transparent as possible about how we do it. We also appreciate that it’s a privilege that you have shared your data, and we take that responsibility seriously.
In this post, we want to go over our approach to data security, how we tackle it and what we do on an ongoing basis to keep it as tight as possible. It may get technical (because some of our audience are technical and want that level of detail), but we’ll also explain things plainly. We welcome feedback on any of the topics below, so please do feed back if you have anything to say or ask!
Our mission and internal guidelines
First, we needed to define exactly what it is we wanted to achieve when it comes to data security. We created internal guidelines that we follow, and we ensure nothing falls outside those as we develop our solutions. Those are listed below:
We work on the “principle of least privilege”
The principle of least privilege states that our system “limits users’ access rights to only what are strictly required to do their jobs”. That is, anyone in our organisation only gets to see personal information if they need to. Otherwise, by default, it’s locked and out of reach.
For instance, our developers never have access to your personal information or records, because, they don’t need them. For our development purposes, we can use fake data to test with, so we leave yours encrypted and untouched.
We have multiple and redundant checks for access to your data
For those times that our team, or your nominees, do need to access your data, we have a number of gateways written into our code that check the privileges of the user, their role, who they are, their relationship to you (for example, are they one of your nominees etc.) before the system will let your data flow through. In many cases, we have a number of those types of gateways, making multiple checks.
This type of approach is also known as the Swiss Cheese Model, in which we add a number of layers of checks to minimise risk.
We only store information we need to deliver our service
As per the UAE guidelines and our Privacy Policy, (and logic), we only ask you for, and collect/store, information that we need to conduct our service to you. This minimises the data you have to trust us with.
We design any feature with security in mind from the start
You can read more on this below in the “Shifting security left” section, but ultimately, our team begin every task by understanding, recognising and acting on security aspects from the very beginning. This means solutions are architected to be secure and respectful of data from the outset instead of an afterthought.
We seek reviews from multiple sources for quality
When it comes to data security, one mind is never as good as multiple, and we must stay on the cutting edge of security as it evolves. Although we review each others’ code internally, we also make use of a number of external, industry-standard security review tools to analyse our code as well. This is part of our workflow, so it happens automatically at every step of our development pipeline, which means we’re getting insights from the industry in real-time on any possible attack vectors.
Storing your data
Our hosting partner is Amazon (or AWS, Amazon Web Services). They are one of the big 3 hosting companies world-wide (the others being Microsoft and Google), and are trusted with some of the biggest online services, including Facebook, Netflix and LinkedIn.
As per the UAE guidelines for personal (and especially health) data, all your information is stored right here on Amazon’s servers, in the UAE. Nothing is sent over the borders to any other country, and if that needs to happen in the future (for example, if we use an amazing new tool to make our offerings to you even better), we will make sure we ask you before we do that.
Encrypting your data
Where possible, we use industry-strength encryption to lock down your data on our AWS servers when it’s not being used (or, when it’s “at rest”). We do this for any AWS service that may use your personal information, including our databases, storage systems, queueing systems etc.
As for data transfer, of course, all our systems communicate with your web browser and devices using HTTPS (the same security method your bank website uses), so any information is encrypted when transiting. We don’t actually allow non-secure communications to and from our servers; we block that by default.
Shifting security left
“Shifting left” in the development and security lifecycle effectively means thinking about security earlier. In some companies, security can be an afterthought: developers designed and build their system, had their QA team test it, rolled it out to beta users and just before they released it, someone would run a security review and discover a number of critical security flaws that needed addressing. Some of these may be so complicated that it means going back to the design stage. Maybe some companies don’t even run security reviews. Maybe they run those reviews after they deploy their product to the world!
Shifting left means that we bring security into our process earlier, right at the design stage. We approach a new feature or fix thinking of the security aspects and impacts that it may have, and work with those from the start.
Tools
At the speed security threats evolve online, it’s impossible for a small team to understand and comprehend even a percentage of them. Because of this, we employ a couple of different external tools and knowledgebases to review our solutions, using both Black and White-box approaches.
Simply put, we have these security services (not named intentionally for security reasons) test our systems from the outside for vulnerabilities, and also internally by reviewing our code for possible weaknesses. We review the reports from both on an ongoing basis, and resolve immediately those high and critical findings before they are deployed.
Your rights regarding your data, and our DPO (Data Protection Officer)
Our Privacy Policy covers your rights to your data in depth, but at a high-level, you have and will always have the right to review, update, add to or delete any data we have for you.
Expertise
Our co-founder and CTO (and the author for this page!) has worked for DarkMatter in application security. DarkMatter (now Digital14) is a cyber-security company writing software and creating hardware for the UAE government and military sectors, and was deeply ingrained in the security aspects of creating software. This background and experience makes a solid foundation for a safe data ecosystem to build MDBX on top of.
Summary
We hope this has shed some light into what we do to protect your data to keep it safe. We hope we’re not an exception; all businesses and websites should take your data security this seriously, so don’t hesitate to ask them what they do to protect you online.
Otherwise, thanks for reading! If you have any questions, please do reach out to our tech team at it@mdbx.health.