Common questions and answers

I am seeing a 401 on my probe. Why?

A 401 indicates an authentication failure, typically caused by not setting the PRELUDE_TOKEN environment variable before starting the probe.

Related: https://docs.preludesecurity.com/docs/probes#authentication

Can I change the default probe check-in time of 4 hours?

Sort of. Probes are coded to check into the Service API every 4 hours. This ensures multiple attempts per day are made to retrieve tests. However, tests abide by run codes (schedules) which dictate how often they should be run. The most frequent run code is DAILY, so increasing the check-in interval will not retrieve more tests. If you still want to update this interval, locate the magic "14400" number inside any probe's source code and change it to the number of seconds you'd like between check-ins.

Related: https://docs.preludesecurity.com/docs/safety#limited-network-requests

Are tests removed after running?

Yes. This is a safety measure to ensure no test can be tampered with between runs. It means they will be downloaded for each new execution - but each test is < 2MB (many under 1MB) when compiled and only a few tests are intended to run on any given machine, daily. Our goal is to leave an endpoint largely untouched, with only the probe process running (no extra files on disk, in RAM, configuration changes to the box, etc.).

Related: https://docs.preludesecurity.com/docs/safety#telemetry

Won't Detect fire off lots of SIEM events?

Yes. Detect runs real security tests that exercise real events, which means your SIEM will be exercised alongside your endpoints.

Because you don't want to miss a real threat actor in the noise, we recommend you attach your SIEM to your Prelude account through the prelude iam attach-control command. Every time a probe runs a test, the result is forwarded to any attached SIEMs, allowing you to separate Detect events from real world threats.

Want to avoid system events from even being recorded on the endpoint? See us about our custom EDR integrations.

The attachment process offers a secondary benefit: you can fine-tune your detection engineering efforts by ensuring each Verified Security Test is observable through a detection rule.

Related: https://docs.preludesecurity.com/docs/defensive-integrations

Why should I run probes on all endpoints instead of a few?

Traditional Breach and Simulation (BAS) architectures recommend running TTPs on only a few endpoints and extrapolating what this means for the rest of the organization (based on similarity of operating systems, defenses, etc.). This is helpful for small-scale security assessments but to get a complete picture of your responsiveness to real events you need to test on every endpoint. Why?

Endpoints - even if starting from the same base image - drift over time. The longer an endpoint is running the more drift occurs. Different processes run on each, different users interact with them, the file system changes, ... Each delta represents unique surface area that should be continuously tested to ensure a single endpoint in your environment isn't drifting too far.

Related: https://docs.preludesecurity.com/docs/the-basics#why

Can I integrate my own tools with Detect?

Yes. Detect is 100% API-driven and all routes are exposed to you through HTTPS. Prelude also offers a set of Software Development Kits (SDK) in different languages, which wrap the API, so you can skip the boilerplate of writing API code. Currently, Javascript and Python are supported.

Related: https://docs.preludesecurity.com/docs/prelude-cli#prelude-sdk

Can probes collect stdout?

Yes - but not by default. When probes run tests, they only send the test identifier and a code representing what occurred on the box. This is to protect your privacy. However, probes are fully open source, so you can extend them to collect additional data points, such as PID or stdout, and pipe it wherever you'd like (such as a SIEM).

Related: https://docs.preludesecurity.com/docs/making-sense-of-results#test-results

Why are security tests written in Go?

Go is a multi-platform, memory safe language that has included a feature called "embed" since version 1.16. Embed allows compiling arbitrary files into Go source code - a feature that enables Detect tests to pre-package all aspects of its test into a single file, without requiring additional download requests. That said, you can write VSTs in any compiled language, assuming you follow the required structure.

Related: https://docs.preludesecurity.com/docs/tests

Couldn't a threat actor use Detect?

All good things will be used for bad in equal measure. However, Detect has several safeguards in place to avoid abuse. First, accounts are limited to 100 tests run per day, unless you request a limit raise. Second, if you want to run custom tests, the code is submitted to the Compute server - a utility hosted by Prelude that scans compiled binaries for malware signatures before making them available for probes.

Related: https://docs.preludesecurity.com/docs/build#validation

Can I run Atomic Red Team TTPs through a probe?

Technically, yes, you can load an ART TTP into a security test and execute it. Before you do however, determine what your goals are. Detect tests (VSTs) produce an output that is binary: the test either worked or didn't, to some objective level of granularity (represented as a "code"). Typical security TTPs output stdout text that must be parsed to understand the impact. However, with some work, most TTPs can be converted into VSTs.

Related: https://docs.preludesecurity.com/docs/making-sense-of-results#test-results

Does Detect work offline?

No, Detect is a SaaS solution and does not allow for offline use. All probes must have connectivity to the Prelude API (api.preludesecurity.com) in order for them to run tests. However, Prelude does allow self-hosting on a case-by-case basis. Reach out to [email protected] for details.

Won't an EDR shut down the probe?

Detect probes are designed to work with defenses, not against them. Each probe runs in a parent process on the machine but each test is executed in a separate child process. As such, the probe generally does not get shut down by antivirus or EDR programs. However, we recommend creating an exception (whitelisting) the parent probe process just in case. We want the defense to be tested on its ability to respond to each unique test, not the probe managing them.

Why map tests to rules instead of a popular framework, like MITRE ATT&CK?

Tests are governed by rules, which describe the constraints of the operating system. In order to truly provide security at the endpoint level, the surface area of the machine needs to be reduced. The difference in security between a Mac and an iPad is extraordinary - a fact due to the architectural differences in surface area. A Mac can close the gap and be "more secure" like an iPad, but only through the process of reducing its surface area to match the tablet's natural state. Tests map to rules because rules enforce the security of an endpoint.

Related: https://docs.preludesecurity.com/docs/verified-security-rules

Won't endpoint defenses simply quarantine all Prelude tests?

Because probes are not attempting to evade the defense, endpoint defenses could just block all tests originating from the probe's parent process. This would make the defense seem capable of detecting and responding to all malicious behaviors. However, Prelude runs a daily health check test by default - a test that has the ability to change its own hash. This test is dual-purposed: it ensures probes are operational and it keeps the defense honest. If the health check is quarantined, it means the defense is "over-catching" by stopping benign behaviors.