About Build

Security Test Authoring

Prelude Build is an easy-to-use IDE - purpose built for authoring, testing and verifying security tests for use in real environments. Our goal is to provide a consistent and repeatable way to write, verify and deploy tests for any scale.

Build can be used through the user interface or the Prelude CLI.

The problem

Build exists to streamline taking a security test from ideation to production. Security testing today is usually restricted to development environments and the results are extrapolated to the rest of the infrastructure.

Below, we'll outline a few of the reasons why this is and discuss how Build injects a standard software development lifecycle to overcome these friction points.

Flexibility

Today, security tests come in various forms and formats: TTPs, YML files, executable code, libraries, scripts, exploit code, POCs and more. Most are purpose-built around a specific command-and-control center (C2). By and large, C2 frameworks are not intended for large-scale applications and TTPs with this tight integration makes them difficult to transfer for wider use.

C2's do not refer to their actions as tests. Some use terms like BOF, COF, procedure, etc.

This is why multiple new C2 frameworks are released each year, often with overlapping functionality. People aren't trying to improve upon the behavior of the testing, but on the tooling around the testing.

Efficacy

The next problem arises when you want to execute an action. There is no standard approach to testing the efficacy of the test (does it work), where it can and cannot run, and gauging what the system impacts are of running it.

Consider that security tests fall into two broad categories:

  1. Those integrated into a C2
  2. Standalone scripts, executables, libraries

A C2 is an execution framework for launching actions against remote agents. There is no concept of a development environment bundled with your C2, similar to how there is no dev environment hanging off your production system elsewhere. In order to gauge efficacy, you have to deploy agents in a fairly involved process that tests the runtime of the C2 as much as your test itself.

Extracting your tests from the C2 allows you to test them independently - and there is precedence for this in the wider technology space. However, security engineers have lacked the same tooling software engineers have enjoyed for years around continuous integration testing.

Software engineers build complex applications that have predictable runtime environments, so IDEs focus on project building and authorship. Security engineers generally build simple single file actions with unpredictable runtime environments, and therefore have been boxed into using IDEs not purpose-built for them.

When testing, there are three things you should gauge:

  1. Does it do what I expect?
  2. What operating systems and architectures can I run it on?
  3. What are the negative impacts of executing this in production?

The solution

Prelude Build can be broken down into the following functions:

  1. Authorship
  2. Storage
  3. Validation
  4. Deployment

Authorship

You start by proposing an idea in question form:

Example: "Is there evidence of LockBit ransomware?"

Then you create a test to programmatically answer it. Tests are currently written in Go, to provide multi platform support out of the box.

Storage

As you write tests, Build stores them in a private cloud account only you can access. You can treat this database similar to git: you can push, pull and clone your files across multiple computers. If you share your account with teammates, you can work concurrently on the same project.

Validation

Any test can - and should - be validated in Build as you develop it.

Build's GUI and CLI act as thin clients connected to a more powerful Compute server, containing the runtime environment for compiling, scanning and publishing your code. When you fire off a test, it is sent to a Compute server, which performs the following:

  • Looks at your filename to decide which test to compile.
  • Compiles your code for all applicable platforms.
  • Scans each compiled binary against known malware signatures to determine if the test is likely to be caught.
  • Publishes the resulting compiled binaries - one per platform - back to your private cloud. We call these compiled binaries "Verified Security Tests", or VSTs for short.
  • Gathers results for all compile and test steps and displays them back in your client.

Build does all compile and validation steps concurrently, so you should experience a similar latency as compiling code locally - only your Compute server will do quite a bit more!

Test outputs are standardized, so you can easily, and objectively, understand their efficacy. Each test will display
the specific status code, seconds it took to run (human not CPU) and debug information from stdout and stderr.

Deployment

Prelude Detect is a system for running Verified Security Tests at production-scale. Learn more.

Once a test has been authored and verified, you can move it to a ready-for-execution state.

In Build, this means generating a deployment URL for it. URLs are pre-signed download links to your test which are usable for up to 10 minutes. Take a URL and plug it into any execution engine or C2 in order to run it. Or use Detect.