Secure development
How we build and ship the software and firmware in our testing systems: what we test, how updates are signed and delivered, and the security posture a GDS system has when you switch it on.
The environment we design for
Our products are not general-purpose IT. A GDS system controls a physical specimen under load, often for weeks at a time, and the integrity of the resulting data may underpin a foundation design or a published paper. That shapes our security decisions in ways that differ from ordinary business software:
- Availability during a test is critical. A control process that stops mid-test can ruin an irreplaceable specimen. Security measures must not introduce a new way for a test to fail.
- Integrity of the measurement is a first-order concern. A results file that has been silently corrupted can pass through analysis and into a foundation design or a published paper without anyone noticing. Confidentiality matters as well, and for some of our customers it matters most — commercially sensitive site investigation, defence and nuclear work, and testing carried out under national restrictions on where data may go. We treat the two as requirements to be met together rather than one to be traded against the other.
- Systems are long-lived. We support hardware generations for a decade or more, which rules out designs that assume frequent replacement.
- Networks vary widely. Some customers run our instruments fully isolated; others have them on a general university or corporate network. We cannot assume either.
Secure by default
A GDS system as delivered:
- Talks to instruments over USB or serial. The control path is a cable rather than a network connection, so there is no network service listening for it and no port for your IT department to open.
- Runs on a PC you supply. We do not ship the computer, so its build, patching and account policy stay yours — see deploying our systems securely for what we recommend.
- Needs no internet access. Nothing in the control path reaches our servers in order to run a test.
- Keeps what little runs between our own components on the loopback interface. Bender element testing is the one part that uses a local network socket, and it listens on this machine only.
Development practices
Across our software and firmware development:
- Source is held in version control with reviewed changes; no change reaches a release branch unreviewed.
- Releases are built by scripted automation from a tagged commit, so a released binary can be traced back to its source.
- Third-party dependencies are tracked per release, so we know what ships in a given version — see software transparency.
- An automated regression suite covers the control and acquisition paths, so a security fix can be shipped with confidence that it has not altered measurement behaviour.
- Security testing and review are repeated through the support period, not performed once before launch.
Signed updates
Our Windows installers and the binaries we write are code-signed with an EV certificate, timestamped, and the signature verified again after signing. Instrument firmware is not signed yet. Before installing an update:
- Windows installers — right-click the file, choose Properties → Digital Signatures, and confirm the signer is Global Digital Systems Ltd. Windows will warn you if the signature is missing or invalid.
- Instrument firmware — firmware comes from us and from nobody else. The controller checks an image against a checksum before applying it, which catches a corrupted transfer but is an integrity check rather than a signature, so the assurance rests on the image having come from us. Signed firmware is planned.
Only take software from us
We distribute software through our own channels and through named distributors. We will never ask you to disable signature checking or antivirus to install a GDS update.
If an update arrives by an unexpected route, or a message asks you to bypass a security warning, stop and contact support@gdsinstruments.com.
How updates reach you
- Security updates are free of charge and available to every user within the support period.
- Where technically feasible we issue security-only releases, so you are not required to accept functional changes in order to become secure. This matters in accredited laboratories, where a functional change to the control software may require revalidation.
- Every security update is accompanied by an advisory setting out what changed, what the risk was, and what you need to do.
Why we do not auto-update instrument controllers
We deliberately do not apply updates automatically to systems in the control path. An unattended restart part-way through a fourteen-day consolidation test would destroy the test, and possibly the specimen. Updates to control software and firmware are therefore operator-initiated, so that you can choose a moment when no test is running.
This is a considered trade-off rather than an omission. It places a duty on us to make updates easy to find and to tell you clearly when one is security-relevant, which is what the advisory feed is for. Components outside the control path, such as reporting and analysis tools, can be updated on your normal IT schedule.
When a component we use has a vulnerability
We assess whether our product is actually exploitable through it before acting. A vulnerable library is not automatically a vulnerable product, and we would rather tell you accurately that you are unaffected than push an unnecessary update into a validated laboratory environment. We can supply that assessment as a VEX statement.
Deploying our systems securely
Our recommendations for laboratory deployment:
- Put instrument control machines on a dedicated network segment, separated from general office IT.
- Do not expose control machines directly to the internet — no public IP address, and no inbound ports forwarded to them. Nothing in our control path requires inbound access, and neither does remote support; see below.
- Keep the host operating system patched and within its vendor's support period.
- Back up results data off the control machine. A control PC is exposed to ransomware, theft and disk failure like any other Windows machine, and a test that has been running for weeks cannot simply be repeated.
- Restrict physical access to control machines mid-test.
- Apply your organisation's normal account and access policy to control machines. Our software keeps no security audit log of its own, so on a shared login who did what is answerable only from your own Windows logging.
If your IT department needs more than that — antivirus exclusions for the control path, or what to allow for a remote support session — ask support@gdsinstruments.com and we will give you the detail for your system.
Remote support
We do assist remotely, and for some faults it is the difference between a fix the same afternoon and waiting for an engineer to travel. That is not a contradiction of the advice above, because it does not require your control machine to be reachable from the internet:
- Outbound, and started by you. Your machine makes the connection to the support session. We have no route in otherwise, and no standing remote-access service is left listening on a GDS system between sessions.
- Attended. Someone at your site starts the session, sees what is done, and can end it at any point.
- Temporary. Access ends when the session ends. Getting back in needs you to start another one.
- Optional. If your policy does not permit remote sessions at all, tell us and we will work from logs, telephone and email. Slower, not impossible.
We use TeamViewer by default, as a one-time session rather than an installed host: you run a small executable, it gives you a session ID to pass to us, and closing it ends the session and removes the access. Nothing is installed and nothing starts with Windows. Your IT department can allow TeamViewer’s outbound destinations specifically rather than opening anything wider, and we will work with a different tool where your policy requires one.