Security tests

Security teams often work in the world of TTPs - or Tactics, Techniques and Procedures. Technically, a TTP is a payload or a sequence of commands that execute a focused behavior on a computer system.

This flexible definition means TTPs can create instability on an endpoint. Behaviors may generate new registry keys, unhook defensive controls, install utilities or perform more destructive actions like deleting files or entire user accounts.

Verified Security Tests (VST) are production-ready versions of TTPs. Tests have characteristics that encourage scale and safety, which are foreign concepts to traditional TTPs. Tests are the lifeblood of the Detect ecosystem: you write them, verify them, publish them and ultimately deploy them into your development and production environments.

What makes a test "Verified"? Prelude puts all tests through a robust testing process to verify their effectiveness and safety.

Read about our journey moving from TTPs to VSTs.

Philosophy

Prelude's stance on security tests is that they should:

• Provide default safety controls to avoid using high system resources.
• Reverse any effects the test had on the system.
• Exit with a granular code to easily understand what happened.
• Compile into a standard binary so the source language is unimportant.

Structure

Tests are broken into two parts: metadata and source code.

Metadata

Each VST has a JSON blob descriptor containing:

• account_id: the Prelude Account that owns the test
• id: a UUID to reference the test programmatically
• name: a short plain-text description
• unit: the endpoint component being tested
• advisory: the particular security advisory the test was coded against

An example is shown here:

{
    "account_id": "prelude",
    "id": "475a9cef-1326-49b4-b59a-d8072c007fd2",
    "name": "Lockbit Ransomware",
    "unit": "advisory",
    "advisory": "AA23-075A"
}

Source code

Source code represents the test implementation. Prelude tests are written in Go, which provides several niceties for authors:

• Default cross-platform support for most operating systems
• Built-in guardrails around memory safety
• Unique capabilities, such as the embed build flag, which are ideal for endpoint testing

Tests are compiled into a set of executable files through an advanced Compute process. This process validates the integrity of each test and prepares it for scheduling.

Source code for the Go test template is displayed below:

package main

import (
	"github.com/preludeorg/libraries/go/tests/endpoint"
)

func test() {
	Endpoint.Stop(100)
}

func clean() {
	Endpoint.Stop(100)
}

func main() {
	Endpoint.Start(test, clean)
}

Endpoint module

Each test inherits a set of functions from the open-source Endpoint module. This module supplies out-of-box approaches to common needs, such as reading and writing files or scanning the internal network. At minimum, each test should start with Endpoint.Start and exit with Endpoint.Stop.