Mydex Security Model and Infrastructure Management
This document provides an overview of the Mydex Safe Secure Cloud's platform infrastructure, with a focus on the resiliency of the platform, its security controls and how day-to-day operational processes enforce rigorous workflows and change management in accordance with Mydex's ISO27001:2022 and FairData accreditation.
These controls and processes are designed and implemented throughout many different layers of the platform to reduce risk, maintain integrity and defend the platform and member data from both malicious and accidental adverse events.
1. High level architecture overview
The Mydex Platform is hosted at AWS (Amazon Web Services) and consumes a variety of services made available by AWS, as well as the custom apps using a variety of mostly open source software hosted on those services (see Components Used).
The infrastructure is both logically and topographically segmented to reduce the attack surface to the outside world.
Several copies of the platform are concurrently run in separate environments to safely develop and test the platform through a best-practices continuous integration workflow.
The core Mydex Platform (referred to as the Mydex 'Safe Secure Cloud') is actually made up of several public-facing API services for third party subscribers / developers/partners to consume as part of their own applications, as well as Mydex-maintained member-facing and subscriber-facing applications which also consume those same API services.
The separate production APIs and member-facing and subscriber-facing public applications are run in distinct AWS accounts as an additional ‘security through compartmentalisation’ hardening measure, designed to defend against a single AWS account’s compromise causing a cascade of compromise against other production platforms.
Within each AWS account, there is similar or equivalent separation of development and production environments with, at the very least, logical network/firewall-based isolations in place to segregate environments from one another.
The diagram below demonstrates how the production environment runs as its own discrete network separate from the staging network with a minimum exposure to the outside world (load-balancers/proxy endpoints with a public-facing NAT, with the application layer in a private network and the data layer further behind that).
Please click the diagram to see a larger version in more detail.
An operational network or backplane is used by the engineering team (which other teams, such as the development team, cannot directly access) to manage the act of deploying changes through automated tooling, as well as monitoring the other environments.
1.0 Description of the platform
The Mydex platform is a collection of applications that are deployed as Docker containers on an automatically and horizontally scalable cluster of compute technology, behind redundant pairs of load balancers which field incoming requests.
This platform is divided up into several 'platform services'. These are the main categories:
- Personal Data Services layer, for interacting with secure Member Personal Data Stores using the PDX API
- an Identity Services (IDaaS) layer for registration and login as a federated authentication system using OpenIDConnect
- Master Reference Data services - non-personal data for enriching other applications using ingested public data such as directories of services, postcodes, health related data from the NHS, and elements of our own publicly facing documentation etc
- Experience Layer - frontend applications which provide a convenient self-management interface to the member's PDS for the member and provide subscriber-facing applications, each logically separated. Like Subscriber applications, Mydex's Experience Layer consumes the Mydex APIs to retrieve/store data in the Member's PDS and does not store the Member's Personal Data itself.
- Subscriber Onboarding services such as our Connection Manager and public Developer Documentation, to help subscribers integrate their own platform into the Mydex PDX and IDaaS APIs.
- The platforms are logically isolated from one another, both at a network level, and at an accounting and access control level.
- All of this helps Mydex pursue a ‘security by compartmentalisation’ goal whereby not only is the data layer logically separated, as well as separation between test/production environments, but even entire platforms are isolated into separate AWS accounts, requiring separate permissions and API credentials to operate.
- This helps reduce the risk of compromised Amazon accounts (or even human error) affecting all aspects of the ecosystem at once.
1.0.1 Real-time resilience across separate physical datacentres
Each component of the platform (for example, Identity Services, or Personal Data Services) runs within a private network (VPC) that is not shared with other AWS customers - and not even with other parts of the wider Mydex Platform.
In each live platform service, the technology stack, including the load-balancer, compute, database and filesystem layers are distributed across three multiple physically-distanced data centre locations throughout London, designed to be spaced far enough apart to resist blast radius catastrophes. (Amazon describes the distance as "meaningfully distant from each other, up to 60 miles (~100 km)... designed not to be simultaneously impacted by a shared fate scenario like utility power, water disruption, fiber isolation, earthquakes, fires, tornadoes, or floods.")
Mydex can tolerate the loss of two entire datacentres out of three and still maintain the live service.
Although the data centres are physically separate, cloud and network technology allows them to be represented as one private LAN spread over separate subnets, making it possible to build, connect and maintain those services together transparently. These datacentres are known as ‘Availability Zones’ in AWS parlance.
Mydex does not perform nor require physical access to the hosting premises in order to maintain the platform as it is entirely cloud-based. The data is encrypted by design and at rest on the hardware, in order to protect the integrity of the data against physical theft of the hardware.
For more information on how the physical data centres are protected from a security context, refer to the published Amazon compliance documentation.
1.0.2 How requests enter the platform
Traffic from the outside world enters through a set of redundant and highly available load balancers. Only HTTP and HTTPS traffic is accepted, with HTTP immediately redirecting to HTTPS. To encrypt the HTTPS traffic, TLS 1.2 or higher is required.
Depending on the nature of the request, the load-balancer’s traffic rules receive the request and pass it to the appropriate backend container (or set of containers) running in the autoscale cluster. Those containers run the applications which then process the request and return the response. The containers are not directly accessible from the public internet - they allow traffic only from the load-balancer, proxied through to the container's running process in the backend.
1.0.3 Scalability and ‘self-healing’ of the platform
The cluster of compute servers which run the containers, run as part of an ‘autoscale’ group. This means that they can scale dynamically to increase resource capability behind the load balancers.
Mydex runs multiple simultaneous copies of the same container across that cluster for added resilience. The cluster runs a set of servers in separate availability zones (again, these are in fact in separate physical data centres in order to withstand physical loss).
The nature of autoscale also means that if a server becomes unhealthy for any reason (e.g. due to an isolated hardware failure), the cluster will build a new server in its place and automatically add it into the cluster.
Containers themselves also are re-spawned on the running server if they become unhealthy for any reason.
In this respect, the Mydex platform self-heals from both physical and software failures, as well as expanding automatically or on-demand to meet increased spikes in traffic. To keep the system economically feasible, it is equally possible to ‘shrink’ or downsize the cluster again once those peak periods pass. All of this is transparent to the end user without any interruption in service.
Depending on the nature of the request, the container and its role in the architecture, other services may be interacted with, such as MySQL databases, which again run on highly available, multi-availability-zone (Multi-AZ) database instances (RDS), or Elasticache (Redis). These technologies variously support active-passive or active-active replication features to ensure there is no ‘data drift’ that could otherwise be detrimental in a failover scenario.
EFS, a highly-available, low latency shared filesystem, is also used to allow the ephemeral nature of containers to access persistent storage data (such as the Personal Data Stores) that needs to live beyond the lifecycle of a typical container.
The shared filesystem has a point of presence in each physical availability zone (data centre) with each compute service accessing the shared filesystem in its nearest data centre point of presence, making it not only resilient, but as fast as possible.
1.1 Testing environments
The entire platform described above is replicated to separate dev and stage/sandbox environments to allow for safe testing and change management in an isolated way. These platforms do not run, rely on or store production data or personal data.
1.2 Operational infrastructure
Complimenting both the staging and production environments is a small set of infrastructure called the ‘operational’ layer. These components provide us with our testing and change management services, such as the use of Continuous Integration and Deployment products for testing and deploying changes to the dev, stage and production platform (e.g. baking new container images with updated code).
Various open source code testing and static analysis tools (which can be found at Components Used) are integrated with the CI/CD pipeline to automatically test the platform as changes are made to it.
Operational access to various tools by the Mydex team occurs via encrypted VPN tunnels. Each AWS account has its own distinct VPN to access that platform's relative internal network. These VPNs use public key cryptography (PKI) and strong ciphers with TLS 1.2 or higher and AES encryption. Each staff member is issued unique certificate/key pairs which are individually auditable and revocable - no shared credentials are used.
1.3 Change management and version control
1.3.1 Version control software
The applications within the platform are all developed through the use of Git version control. The use of Git version control allows for:
- a strong audit trail of change sets
- peer review processes to ensure ‘many eyes’ spot problems or deviation from our coding standards and help improve the collective knowledge and skill of the development team
- reversibility of changes should they introduce problems
- branch separation for discrete development of features vs bug fixes
- branch separation and use of ‘tagging’ for deployment of different versions to different environments
- the ability to reuse components as smaller git repositories of their own across the platform to reduce duplication of code and effort, and speed up the development of new applications
The continuous integration tools used by Mydex are tightly coupled to the use of Git in such a way that git ‘events’ are capable of automatically triggering testing and deployment of new changes into our development environments.
1.3.2 Infrastructure and configuration as code
The tech stack is provisioned and maintained using state-of-the-art and open source infrastructure-as-code tools such as OpenTofu, allowing us to define all of our infrastructure ‘as code’ in a declarative way.
Defining all the infrastructure as code allows us to manage the infrastructure in Git version control. This means that building and changing the infrastructure is subject to the same rigorous peer review, auditability and revertability as the Mydex applications themselves.
What runs on the operational infrastructure, once provisioned with OpenTofu, is maintained thereafter using Ansible, another industry-standard configuration management tool that also is version-controlled with Git.
2. Technical stack specifics
The Mydex Safe Secure Cloud runs on GNU/Linux and open source components wherever possible.
The Mydex Safe Secure Cloud consumes various cloud services made available by AWS in order to serve the applications. This includes VPC networking, Load Balancing, Compute clustering and container orchestration services, as well as database engines (RDS) and elastic storage (EFS).
Mydex also uses other cloud vendors as offsite disaster recovery services in order to maintain vendor-agnostic business continuity of certain data. These services use encrypted-at-rest disks (LUKS) to maintain the same or similar level of data protection as the primary platform.
Please also see Components Used for more detail.
3. Coding/Engineering approach
3.1 Zero touch deployment of applications
All code is kept in Git repositories for change management and peer review.
Code is developed in discrete developer environments and then issued as ‘pull’ or ‘merge’ requests in Github for peer review.
Our continuous integration layer detects when a PR is made (or has commits pushed to an existing PR) and:
- Statically tests the code at PR level for quality purposes
- Conducts dependency vulnerability issue
This helps address issues as part of the peer review process.
If the code meets acceptance by peer review, it is then merged into a test environment whereby our continuous integration layer:
- Automatically detects the change
- Builds a new version of the container image with the new code
- Deploys the updated container image into the container repository
- Triggers a change in the Amazon Elastic Container Service (ECS) to notify it that a new version of the container image is available.
Amazon’s ECS then:
- Deploys a new container for that app, based on the new container image
- Waits for that container to start responding healthily to health checks by the load balancers
- Begins a process of ‘connection draining’ the original container running on the previous version, to allow long-running requests to complete gracefully. All new requests start going to the new container
- Decommissions the old container.
Our CI/CD layer then performs further tests against the application that is now running the new code.
The entire process described above is automated.
3.2 Automated approach to systems administration
As described earlier, all infrastructure is defined ‘as code’, which means the infrastructure - right down to the DNS domain management - can be rebuilt from manifests.
The application layer is deliberately designed to run in scalable ‘clusters’ of semi-ephemeral servers which can come and go to meet demand or as part of routine patch cycles.
Servers that are not ephemeral, such as the operational layer, are still provisioned with OpenTofu but have their long-term configuration managed using Ansible, a config management open source tool.
4. Security
4.1 Firewalls
All components use Network ACLs and Amazon Security Groups with a ‘deny by default’ approach to the firewall, both inbound and outbound.
4.1.1 Inbound firewalls - AWS layer
Only ports necessary to be open to the outside world are made open. Those are usually port 80 and 443 (HTTP and HTTPS) on the public-facing load balancers (ALBs).
All HTTP (plaintext) traffic is redirected to HTTPS (TLS1.2+) by the load balancer before the traffic even reaches the underlying application’s Nginx web service. Only the frontend web apps are accessible to the outside world.
Mydex also uses Strict Transport Security headers to encourage the enforcement of optimistic upgrades by the browser to HTTPS before traffic leaves the member’s or subscriber’s browser.
4.1.2 Inbound firewalls - software layer
Wherever possible, a second, Ansible-managed software firewall is also deployed on servers for additional ‘defence in depth’ beyond the Network ACL and AWS Security Group layer.
4.1.3 Outbound firewalls
Mydex implements policies for the outbound firewall - both at the software layer as well as the outbound network layer AWS Security Groups.
The 'deny by default' approach limits the ability to use common ‘amplification’ attacks against other third parties (e.g. against memcached servers and the like), or limiting the ‘pivoting’ potential, should an attacker gain a foothold into the service.
4.1.4 Automated network port scanning
Mydex runs automated, regular port scanning of its network, which will alert the systems and security team if any ports have unexpectedly been opened to the outside world, ensuring prompt detection of any mistakes or malicious modification of the firewalls.
4.1.5 Handling traffic floods
It may be that a remote IP (or range, or range of ranges) sends a lot of traffic to our platform's ingress endpoints. The nature of this traffic can vary in its technique:
SYN Floods e.g.common DDoS at network level
The Amazon ALB (Application Load Balancers) have built-in capability to resist SYN floods at a level 'above' our configurability of the ALB.
Quoting from AWS's whitepaper:
Application Load Balancer blocks many common DDoS attacks, such as SYN floods or UDP reflection attacks, protecting your application from the attack. Application Load Balancer automatically scales to absorb the additional traffic when these types of attacks are detected. Scaling activities due to infrastructure layer attacks are transparent for AWS customers and do not affect your bill
App-specific filtering
Our ALBs are set up in such a way that traffic is only routed to one of our applications if the actual request matches a service that is running in the cluster. In other words, attacks that target the IP address of the load-balancers themselves but not a specific app on our cluster are simply rejected with a 503 as they hit a 'catch-all' target group that serves no actual application.
Application-level attacks
For scenarios where an IP or range is attacking an actual app in our application, our OSSEC intrusion detection systems will alert engineers to a high rate of request errors. From there, the sysadmins are in the position to gauge the severity of the attack and take documented incident response actions as is deemed necessary given the context.
4.2 Cryptography
4.2.1 TLS (websites, VPN tunnels)
Mydex requires TLS 1.2 as a minimum TLS protocol (Mydex services default to TLS 1.3 if the HTTP client supports it) and use Perfect Forward Secrecy ciphers, along with HSTS (Strict Transport Security headers) to best protect the connecting user.
Wherever possible, Mydex uses public key cryptography (PKI) for authentication to internal infrastructure, such as with VPNs and SSH encrypted tunnels.
4.2.2 At-rest encryption of storage
Mydex uses at-rest encryption of cloud storage volumes and buckets. These use industry standard AES-256 / AES-GCM encryption.
See more info provided by AWS here and here.
4.2.3 Encryption of Personal Data Stores (PDS)
See the section on SQLCipher in 4.5.2 Member secrets and protection of personal data.
4.2.4 GPG encryption of data at operational layer
Mydex uses GPG encryption for some aspects of attribute encryption at rest as well as bolstering the security of certain backup data.
4.3 Authentication (authn) and authorisation (authz) protocols
Mydex's Identity Services layer offers OpenIDConnect as a way to achieve Single-Sign-On (SSO) with one set of credentials per member (a 'MydexID').
Not only is Single-Sign-On achieved with OpenIDConnect, but so is Single-Sign-Out, ensuring that upon logout of one app, the MydexID's session is revoked on all other active apps that they may have used since logging in.
Mydex also uses OAuth2.0 (the underpinning of OpenIDConnect) for server-to-server authentication and authorization to its APIs - both from applications that Mydex operates, as well as Subscriber applications that talk to the APIs.
All such use of OAuth2.0 is logged and auditable. All OAuth2.0 credentials are scoped carefully to the appropriate needs, and the APIs inspect the scopes to make sure that not only the access token is valid but that it is authorised to make the request.
The use of OAuth2.0 also means that the access tokens used in the request are short-lived (1 hour lifespan) and expire, rendering them useless later should they somehow leak. Mydex can and does rotate OAuth2.0 and OIDC credentials as required.
The Mydex platform can also integrate a member's PDS with third party Identity Providers (so long as they support OpenIDConnect auth flows), making it even easier for citizens to be onboarded if they have other identities with those providers.
4.4 Monitoring and intrusion detection
4.4.1 Intrusion detection systems
Mydex runs OSSEC, an open source intrusion detection system on all its infrastructure.
OSSEC performs real-time log analysis, attack detection and other system anomaly detections which provide a holistic indication of threats targeting the platform and the sorts of attacks being performed (which also indicate trends by grey hat and black hat researchers as to the sorts of common weaknesses being hunted for).
These events are sent as notifications to the sysadmin and, where appropriate, the development team (such as unexpected application errors), which are continually reviewed by the hour.
Other rootkit detection systems are also in place which perform routine scans and notifications of any unexpected changes.
4.4.2 Availability and Capacity Monitoring
Mydex runs 24/7 monitoring of availability or capacity issues across the platform. This is done using a combination of internal and external monitoring tools, as well as cloud-native metrics provided by AWS.
All of these tools measure the current state against pre-defined thresholds. Should the state exceed or fall below the expected threshold, alerts are sent out to the systems administration and development teams for responding.
This alerting system runs 24/7 and there is a perpetual operational staff presence both day and night to respond to any such issues.
Most of these tools are made consumable by internal dashboards for engineers, the CISO and auditors to view and generate reports from.
4.4.3 Threat intelligence and ‘backchatter’
Mydex is enrolled in NCSC’s “Early Warning System”, leveraging the NCSC’s resources to identify similar ‘backchatter’ for evidence of any leaks that haven’t been responsibly disclosed to Mydex.
Mydex's use of OSSEC as an intrusion detection / anomaly system is a core part of our Threat Intelligence as it alerts engineers in real time to suspicious activities on the platform
4.4.4 Incident response playbooks and post-incident reviews
Mydex maintains internal sysadmin documentation that explains key thresholds and metrics currently configured across the different monitoring platforms, with alert scenario playbooks to make incident response activities easier and consistent. Monitoring metrics are reviewed monthly to identify and discuss events and what further mitigations may be appropriate to avoid recurrence.
4.5 Secrets management
4.5.1 Operations/infrastructure
Secrets management at an infrastructure level is done with a variety of PKI encryption tools (which make use of the open source GnuPG library) that integrate into AWS and the OpenTofu and Ansible products wherever sensitive attributes may need to be interpolated to provide functionality, whilst remaining encrypted at rest.
4.5.2 Member secrets and protection of personal data
Mydex’s mission of providing secure personal data stores (PDS) to members is a separate form of encryption/key management whereby the user’s private encryption key is known only to the member.
The design of the system is such that the member has the agency to grant access to elements of their PDS to connecting organisations without those organisations (or Mydex) needing to know the member’s Private Key.
Members’ Personal Data Stores are, in essence, a combination of encrypted SQLite databases using the open source SQLcipher variant of SQLite, with meta files that define logical access controls for the various connections that may have access to elements of the PDS.
The SQLcipher databases are per member (as opposed to one big database with one key to unlock them) which further mitigates the impact of a leak of the databases themselves (each database would need enormous compute power to crack one member’s database let alone all of them as they all have different keys).
The SQLcipher system keeps the SQLite database encrypted at rest. The disk volumes themselves which store the SQLCipher databases are also encrypted at rest to protect against malicious access from a theoretical exposure to other AWS customers or attack on AWS’s infrastructure.
Read more about SQLCipher's specific security properties such as key derivation/iteration, IV and salts here.
4.5.3 Protecting data at the browser's edge
Even though the server-side infrastructure is very well secured and heavily monitored, increasingly it is the 'client side' (e.g.a person's web browser) that is becoming the target for data exfiltration or phishing attacks that steal credentials.
This is because:
- it is often easier to exploit issues in browsers or in website functionality as it renders, rather than break through into the backend.
- the browser is what holds the session information or experiences data input that can be keys to identity theft or privilege escalation.
Mydex is in the business of securing personal data and so wants to do its best to protect the member even outside the boundary of the Mydex infrastructure itself.
Mydex uses automated tests to ensure that session cookies have the ‘Secure’ and ‘httponly’ flags enforced, as well as Samesite set to Lax or Strict wherever possible.
Mydex also implements Content Security Policy headers which are as strict as possible (little to no third party assets are allowed access, no unsafe inline javascript wherever possible, etc).
CSPs are designed to limit what functionality the web browser is allowed to perform: such as the ability to load an iframe content, or whether inline javascript is allowed to be executed on the page.
All Mydex applications use CSRF tokens to guard against malicious third party tampering with data on pages that can invoke state changes (such as submitting forms).
Mydex also uses Referrer-Policy headers and ‘noopener’ tags in links to prevent the unintentional leaking of data to external sites should the user click away from the application.
All of these measures - among more not mentioned here - are designed to try and protect the member’s data when they are logged into a service, from any malicious software or MITM attacks on the member’s device or network.
4.6 Multi-factor Authentication
Mydex mandates the use of multi-factor or two-factor authentication (2FA) on all third party services that are depended upon, such as AWS accounts, Github, and Google G-Suite.
On Mydex's own platform, multi-factor authentication capability for the MydexID (TOTP, SMS, Email, Backup codes) is also integrated, allowing Mydex Members the ability to secure their data when logging into services that use the MydexID.
Unlike other platforms, at Mydex the MFA 'seed' secrets for the member's MFA are stored in the member's own encrypted PDS, not in some central database where seeds could be leaked in bulk.
Use of valid or invalid MFA tokens are logged in the Mydex logging systems, as well as in the member's own Identity Services Log in their PDS for their personal auditing needs.
Further work is ongoing/planned such as support for WebAuthN (e.g.hardware security tokens like Yubikeys) and other FIDO2-compatible browser innovations such as Passkeys.
4.7 Patching
Mydex runs a rolling patch cycle across the platform every day in alternating batches.
Patches are deliberately not deployed to all environments or systems at once, in order to safely identify any regressions before those same changes are applied more broadly.
Sysadmins are subscribed to patch notification channels and many of these, as well as known EOL dates for certain software components, are also automatically announced into Mydex's internal project management issue system.
4.8 Securing staff endpoints
Mydex recognises that systems administration personnel represent a higher value for compromise due to having elevated privileges in order to carry out their duties.
In accordance, sysadmins, whose threat model is higher than that of certain other staff, are especially encouraged to maintain a personal operational security posture that meets the reality of those risks. This includes the use of:
- ‘compartmentalisation’ operating systems such as QubesOS, which isolate entire filesystem and key management devices from one another (including networkless ‘vault’ VMs for key storage).
- the separation of personal vs work computing devices.
- the use of multi-factor or two-factor authentication wherever possible, especially favouring Hardware tokens such as Yubikeys wherever possible.The use of strong encrypted messaging tools such as Signal and Keybase to communicate securely with one another, with those cryptographic keys verified to ensure they are legitimate.
- The use of ‘ephemeral’ or ‘self destruct’ features in those messaging tools to reduce the exposure of historical information at a later date.
All staff use fully patched operating systems - usually Linux or MacOS-based - that have encrypted disks and are not accessible to the outside world.
Isolated development systems are run at AWS where they can be managed by the sysadmin team. They are accessed by the development team's IDEs through VPN+SSH encrypted tunnels. In effect, the developers' own workstations are merely ‘thin clients’ with a lower-than-usual attack surface, and the sysadmin team are able to maintain visibility on the area that has the most tooling and interaction with the supply chain.
4.9 Phishing and security training for staff
Mydex staff are trained to recognise phishing and other social engineering attacks, and understand to escalate occurrences of these attacks to the CISO per our ISO27001-approved ISMS.
Phishing's vector is most commonly via email protocols, typically with forged 'From' addresses to make the emails seem very convincing.
The Mydex sysadmin team has gone to great lengths to implement the use of DKIM cryptographic controls along with SPF and DMARC policies to greatly reduce the occurrence of e-mail masquerading as Mydex to be treated as legitimate.
Mydex performs Threat Modelling internally and maintains a matrix of threat vectors and their mitigations. Understanding of this matrix is integrated into the staff induction and security training lifecycle. Security training regarding how to write secure code, understanding secure cookies and Content Security Policies also forms part of the Induction Programme for each new team member when they start. Periodic ISMS quizzes are also performed to gauge team retention of policies and ensure best practices are being maintained.
4.10 Vulnerability Management
4.10.1 Managing 3rd party dependencies in code
The Mydex applications follow modern development techniques which make use of third party libraries and other dependencies in order to avoid ‘reinventing the wheel’ and ‘Not Invented Here syndrome’.
There is always the risk that a third party library becomes independently compromised, leading to a ‘chained’ attack against downstream applications that consume that dependency.
Mydex uses industry-standard package management tools (such as Composer and NPM package lock files) for enforcing signature integrity of dependencies. These tools’ lock files are kept in git version control so that every developer is working off the same consistent set of dependencies and versions.
Mydex uses Trivy to scan the lock files and identify available security updates in those third-party components.
4.10.2 Managing 3rd party dependencies libraries in operating systems
Operating system software updates and installation of new software heavily depends on GPG key verification of the repositories that host the software. This is baked into how package repositories work in Linux operating systems.
Mydex avoids using anything but the official supplier repositories wherever possible.
Rootkit detection tools keep track in real-time of whether a binary, script or configuration installed on a system has been modified unexpectedly.
4.10.3 Static Analysis on code
Mydex runs Static Analysis tools such as SonarQube which scan the codebase during the development lifecycle (via IDEs as well as via automated Peer Review when pull requests are made in Git) to look for bugs, poor quality code but also vulnerabilities.
4.10.4 Vulnerability Reporting Procedure
Mydex adopts the 'Security.txt' reporting standard (RFC9116) and publishes a means for ethical security researchers to contact Mydex regarding vulnerabilities identified in the applications or APIs. Please see the Vulnerability Reporting Policy.
4.11 Server hardening
Mydex uses the ‘Dev Sec Hardening Framework’ to apply best-practice configuration hardening settings on both operational and auto-scale cluster servers, many of which are derived from the NSA’s own baseline compliance targets for running a secured Linux installation, as well as those of other industry leaders.
4.12 Domain security
Protecting the actual infrastructure of running services is not enough. Domain theft from registrars, or man-in-the-middle attacks on the DNS, is also a threat.
Mydex uses a registrar that offers MFA and 'domain lock' functionality, as well as DNSSEC.
4.13 Security Testing schedule
Mydex's platform is complex and requires a number of different tools to test each aspect. Many of the testing approaches have been described above already.
Here are some examples of the testing Mydex does, and their cadence.
| Type of test | Frequency | Method |
|---|---|---|
| SSL/TLS protocol and cipher strength test | Nightly | Automated |
| API Tests | Upon each deployment, recurring for some services | Automated |
| ZAP baseline penetration and header tests | Upon each deployment | Automated |
| OpenTofu security scanning via trivy/tfsec (testing for misconfigurations/lax permissions/firewalling etc) | Nightly and after each change to the 'infrastructure as code' | Automated |
| Network reachability tests (looks for unexpected open ports accessible from the internet) | Weekly at minimum | Automated |
| Supply chain dependency tests | Upon each commit to a PR or as CVEs emerge | Automated |
| Static Analysis of code (includes vulnerability testing as well as bugs, smells) | Upon each commit to a PR | Automated |
| Deep penetration testing | Adhoc as requested or as part of major code changes/refactors | Manual/semi-automated |
4.14 Virus scans and detection
Mydex runs a range of virus scanning and rootkit detection tools across the platform as part of its intrusion detection measures.
These tools monitor malicious activity in traffic logs but also on the filesystem, detecting when binaries, scripts or configurations change, and alerting the engineering team when this occurs.
Mydex has used a set of hardening manifests for its Linux servers as part of the Ansible configuration stack which helps Address Space Randomisation, lockdown of kernel parameters and more. See section 4.11 for more information.
4.15 Access control to systems and protection of data at rest
4.15.1 RBAC
Mydex has a robust RBAC Matrix that defines which staff/teams can access which components of the platform. In general, only the sysadmin team can access production systems directly, while developers are limited to development environments only (which do not contain production data).
This Matrix is maintained by the Security team and requires formal approval in our project management system by the CISO for any changes.
The RBAC policies are enforced via infrastructure and configuration as code (OpenTofu, Ansible).
4.15.2 Access to system backends
SSH access to servers requires both VPN and SSH public key (not password) authentication through the private encrypted network tunnel. In most cases only the sysadmin team has SSH access to such services through bastion hosts. There are no SSH ports open to the outside world.
4.15.3 Access to logs
Grafana Logs are encrypted at rest.
Logs that are sent to the OSSEC server also end up on the OSSEC monitor server’s disk, which uses encrypted volumes.
All human access to logs - e.g. reading, parsing, querying them - requires authentication Grafana, which is only accessible to a subset of approved Mydex staff via internal, encrypted VPN and OpenIDConnect. This access is read-only (logs cannot be tampered with).
5. Logging
5.1 Application Logs
The Mydex applications log all appropriate events which get syndicated to two places:
- Grafana/Loki, a centralised logging ingestion system that allows querying, graphing, alerting and metrics to be measured.
- OSSEC intrusion detection and log analysis for anomalies or rule violations.
5.2 Intrusion Detection Logs
The OSSEC intrusion detection logs ingest both web traffic and system/application logs for evidence of anomalies or attacks. These trigger real-time as well as scheduled notifications to engineers via a variety of mediums.
The logs can also be queried to generate reports for certain types of ‘event’ e.g. ‘unsuccessful login attempts’ but also successful attempts that may be legitimate. The rate at which certain events arrive in the logs can also be used to dictate certain ‘active response’ behaviour such as blocking an account if it is deemed to have had too many brute force attacks against it, and so on.
Login/logout events also get logged to the member's own PDS for their own audit trail needs. In some cases, Mydex also automatically emails the member if a high rate of failed MydexID password or Private Key attempts is detected on their account, along with GeoIP information about the source of the requests.
5.3 Sanitisation of Logs
Mydex takes great care to customise its web traffic and application log messages such that the logs themselves do not become a risk factor in terms of unnecessary exposure of data.
Typically, only development environments, which are not public-facing, enable debug log levels in order to aid development and problem solving. Production or public-facing environments do not expose stack traces, version numbers of software and the web traffic logs have URLs and query parameters masked. Limited collection of data helps protect that data. The CI/CD pipeline explicitly performs pre-flight checks that these debug log values are turned off when deploying to production
5.4 Analytics
5.4.1 Member Activity Log
Each member has an internal ‘activity log’ or ledger in their own PDS which contains event information such as login/logout/MFA activity, approval of Connections to their PDS, as well as changesets of write/update/delete requests to data and by whom, which only they can view. The member can view and verify these events by inspecting/exporting their full PDS.
5.4.2 Operational analytics and metrics
Mydex's logging/Grafana system does log the number of requests to the Mydex APIs (and from which subscribing organisation and the OAuth2.0 client that was used to authenticate the request), when requests begin and when they end (tracking a unique random request ID with each request for troubleshooting purposes), along with other internal events such as when members login, logout, or approve data sharing agreements with subscribers. However, it does not capture personal data.
6. Backups
Mydex maintains backups for a variety of the components which have a varying cadence depending on their context. In some cases, data is backed up hourly, others daily, along with a range of incremental and 'full' backups at different cycles.
Mydex often maintains backups of the same data via multiple backup technologies and to different destinations (including offsite locations) to provide a 'belts and braces' multi-layered approach to ensuring no single technology is depended upon for all data protection.
Backups are tested via a battery of restore procedures quarterly with evidence collected for auditing purposes later. Different engineers alternate at performing these tests to ensure balanced familiarity with the process.
7. Handling Deletion requests and SARs
Members can submit support requests via membersupport@mydex.org to request deletion of their data or a Subject Access Request. It is also possible to submit deletion/reset requests via a form here. Both techniques enter Mydex's issue tracking project management system and require authenticity checks before carrying out the request.
Unless otherwise requested by the member, Mydex backs up the member's data before deleting it, in case they change their mind and ask for it to be reinstated within a 6 month time window, which is explained in the Member Terms of Service.
As a precautionary security measure against data leaks or data correlations, a MydexID cannot be reused after it is deleted and a Member must choose a new MydexID if they decide to re-register.