I believe that real security is transparent. Security through obscurity is all well and good if that’s the best you can do… but if you have large scale enterprise customers who work within highly controlled, heavily regulated environments, then, “I would tell you how we do that, but then I’d have to kill you!” is not really a satisfactory answer. When it comes to data security, you need to have the answers to the tough questions at the ready.
Real security stands up to scrutiny. Tachyon was built, from the ground up, with security in mind. We’ve always been aware that Tachyon could be targeted by bad actors with the aim of subverting it and using it as an attack vector. Like any tool that can query any data from an endpoint and take remediating actions when required, Tachyon needs “admin” or “root” access to a device. From the initial concept and the original architecture on up, we’ve always built the software to be as secure as possible.
There are three particular areas I’ll discuss here:
- Endpoint/Server comms
- Data encryption
- Management of Extensibility
1. Endpoint/Server comms
From the start, we wanted to ensure there was nothing listening on the endpoint. If the server was to initiate comms to the endpoint, then the endpoint would have to have a port open, which could be, potentially, an attack vector. So… there’s nothing listening on our endpoints for connections.
When the agent service starts up, it initiates an outbound connection to a Tachyon “Switch” server. These “Switch” servers are part of what makes Tachyon truly unique. They are called a Switch because, like a network switch, they communicate directly with each endpoint. Each Switch process can maintain 50,000 concurrent connections. A single server can run 5x of these processes, meaning 250,000 endpoints can connect to a single Switch server. Several of these can be federated into a single environment. Tachyon is scale tested to 1.5m endpoints, concurrently connected to 6 Switch servers.
The endpoints use standard PKI (TLS 1.2) to pass a cert to the Switch, which checks against the CA to confirm that it can trust this endpoint. It then, in turn, sends a cert back to the endpoint. Now we have bi-directional non-repudiation – and the basis for encrypted comms between the endpoint and the Switch moving forwards.
The data connection is direct between the endpoint and the Switch. Unlike other tools which use peer-to-peer “chains” to pass unencrypted data amongst endpoints, there’s no other party involved here, and we’ve no open TCP port to connect to or attempt to abuse, hence Tachyon is not as open to abuse from man-in-the-middle attacks as other tools.
2. Data Encryption
As we’ve seen, we now have certs on both ends of the comms channel, so we use these to encrypt the comms between endpoint and Switch. But… there are three other areas where data comms needs to be considered:
- Browser to Web Server
Secured with HTTPS. - Tachyon Core to Tachyon Switch
All comms are configurable to be HTTPS based. - Data at rest
There are two places that data is held at rest. One on each endpoint, in a small database which is part of the agent. This is encrypted with AES 256. The second is the set of two databases that form the “Core” of Tachyon, these are MS SQL Server databases, and as such have TDE encryption on the data and log files.
From soup to nuts, everything is encrypted.
3. Management of Extensibility
This one is critical. Tachyon is extensible, you can make it do anything by creating or editing “Instructions”. These instructions (which are treated as either “Questions” or “Actions” in Tachyon) can leverage the hundreds of built-in Agent functions or, can simply embed a binary or script and execute it. Ergo, you have the ability inherent in this tool to have any endpoint do anything – which is wildly powerful, but, as Stan Lee warned: “With great power comes great responsibility”.
Again, we’ve had this in mind from the earliest days and have designed an architecture that deters the abuse of this functionality by bad actors.
First off, and most importantly, all Tachyon Instructions are code-signed with a certificate. The thumbprint of certificates which are trusted by your specific installation of Tachyon are embedded in your license for Tachyon. If someone took a validly signed instruction from a different installation, it wouldn’t work on your installation unless you had specifically allowed it.
Beyond that, there’s Role Based Access Control which limits which users can put instructions into the system, there’s audit logging of changes to this area, and to create an instruction you need a specific tool which is only made available to supported customers and partners.
Conclusion
We take security very seriously with all of our products in 1E. 31 million endpoints worldwide run 1E software for one purpose or another. We are even more painfully aware of the risk of exploit or vulnerability when it comes to Tachyon.
We pen-test Tachyon regularly, changing the third parties testers every few months. Because we’ve taken security into consideration from base principles and architecture, I am glad to say that our pen-testers have given us high marks across the board.
If you would like to pen test Tachyon or use it during a Red team/Blue team exercise as a PoC, please do get in touch.
