Safety

Detect is designed to run in production environments at scale, whether that means 100 or 100,000 endpoints. To be confident running at that scale you should become familiar with the safety mechanisms designed into the system.

Detect probes are designed to satisfy both functional and safety requirements. To achieve both without compromising either, probe structure and code are simple and open, allowing users to examine and verify their functionality. Because the code is open, users can make suggestions (in the form of a pull request) or fork the code and modify it to suit your specific requirements.

Probes

Below are the safety mechanisms built into probes.

Open-source

Detect probes are fully open-source. You should never run a binary on your production systems without first validating the code - regardless of how much you trust the provider. Prelude believes transparency is the key that unlocks good security, so we made all our probes open-source. If you're comfortable, we advise users to read the source code and ask us questions.

• Windows: source code
• Linux/MacOS: source code

Lightweight

Detect probes range from 1-2KB in size, or 30-100 lines of code depending on which one you select. The common rule of thumb is that 15 bugs, including security vulnerabilities, exist for every 1000 lines of code. By decreasing the probe's footprint, safety is conversely increased.

No dependencies

Detect probes require 0 dependencies - beside the standard language they are written in. By removing all libraries, even common ones, probes do not inherit risk from external sources. This also means probes are safer to provision and upgrade, as there are less compatibility problems.

No installation

Detect probes do not require installation. Instead, they are ephemeral processes that run as long (or short) as you want. To start a probe, either include it in your own code or download and start a standalone probe binary. Probes are incredibly small, weighing in between 1-2KB in size, depending on which you choose.

No special privileges

Probes are designed to be run as a "normal" user. Unlike most endpoint agents, we advise against running the process as root or administrator. This immediately limits the surface area and restricts the process to user land.

Limited network requests

Probes do not require a constant network connection to the Prelude Service. In fact, we don't use sockets at all. Instead, probes initiate a handful of requests per day to the Service API over HTTPS. Each request passes the endpoint's platform, architecture and token into the API and asks if you've queued any tests for it.

Resource controls

When a probe isn't making one of its few requests per day, it's dormant. Probes do nothing except make their requests and execute any returned instructions. When running instructions, probes limit their runtime to a few seconds per test. If a test exceeds this limit, it is stopped and a timeout code is sent back to your dashboard for you to review.

Authority validation

When a probe receives a security test to run, it's actually receiving a pre-signed redirect URL to the location where the test is stored. Redirect URLs point to an S3 bucket controlled by Prelude. All security tests are stored in this bucket, specifically earmarked for your account.

Prelude takes rigorous measures to secure and audit our S3 resources. If you'd like information on our process, just ask.

If you set the optional PRELUDE_CA environment variable (before starting the probe), it will validate the redirect location is expected:

export PRELUDE_CA="prelude-account-prod-us-west-1.s3.amazonaws.com"

Telemetry

Probes are designed to ship as little data off each device as possible. They do this by capturing a single code (integer) per executed test and only that code, and the test identifier that ran, are sent to the Prelude Service. These codes are checked against our lookup table so we can build a picture of what occurred on the endpoint.

Tests

Below are the safety mechanisms built into tests.

Test cleanup

Security tests have two parts: the test and the cleanup. The cleanup is run in a separate process from the test and will reverse any effects (if any) that your test created during runtime.

Test compilation

Each test that Prelude authors and makes available inside Detect goes through a rigorous manual and automated test cycle. This cycle starts with manual code reviews and testing across commodity devices. This testing is done by the internal Prelude security team.

Once complete, a test is scheduled inside the autonomous Prelude Test Range, a collection of all major/minor operating systems supported by Detect. When a test is first uploaded, it is sent to the Prelude Compute server for compilation. This server ensures all tests are consistently compiled and then scanned by all (open-source) YARA signatures hosted by Virus Total. This step is done to separate tests from code that is harmful.

The Prelude Test Range then runs the test on repeat, under different circumstances, for at least 3 days to ensure it is production ready. The range automatically changes configurations, endpoint protections, settings and more to provide variance in the testing.

Once a test passes all steps, it is uploaded to Detect and made available for scheduling.

Auditing

All user interactions are logged and made available to Administrators for auditing purposes. You can retrieve the audit logs for your account through the Prelude CLI:

prelude iam logs

You will receive a response containing the timestamp, user, and event:

[
  {
    "@timestamp": "2023-04-12 12:07:56.435",
    "account_id": "0b5319f5cf8ba14cdef96afd0fdada99",
    "user": "[email protected]",
    "event": "register account"
  }
]