Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Testing and validation

Atomic Habits, atomic tests

Three small steps for regular testing, one giant leap for your security program

Keith McCammon

As it enters its fifth year post-publication, Atomic Habits by James Clear continues to shape the conversation on building systems that work for setting and accomplishing goals. If you’ve not yet read Atomic Habits (which you should!), James Clear offers a free 30-day email course, “30 Days to Better Habits: A simple step-by-step guide for forming habits that stick” that I’ve found both informative and actionable. Here’s a peek at three things you’ll learn in the early lessons:

  1. Choose a habit that is representative of what you want to become
  2. Choose a habit that is as easy as possible to perform
  3. Fit your habit into your daily routine

In reflecting on how we might leverage these, their applicability to security testing immediately comes to mind. We’ve blogged, tweeted, and talked many times about the importance of testing security controls and processes on an ongoing basis. One thing we’ve never done is provide a clear framework for setting an atomic training program in motion. As an added bonus, we’ve provided a free tool that will make it easy to track and measure your progress.

Applying James Clear’s three-step process with Atomic Red Team

1. Choose a habit that is representative of what you want to become

In this context, what we want to become is a security program that assumes nothing when it comes to security controls or incident response. If it hasn’t been tested and proven, we can only assume that it won’t work when it matters. We’re choosing to build confidence in our security architecture, processes, and controls by testing these things on an ongoing basis, ultimately becoming a more mature and resilient organization.

Action: Select one technique and Atomic Red Team test every week

Visit https://atomicredteam.io/atomics, find a test of interest based on the technique name, tactic, or target platform. That’s it. Of course, it’s important to select a technique and test that is relevant to your environment. If you’re able to rely on an in-house threat intelligence program, select a technique based on the threats your organization has prioritized. The same applies if you work with a partner who can help you identify high-likelihood, high-impact adversary techniques. If neither of these applies, a great place to start is with a freely available resource, like our own Threat Detection Report, that makes it easy to identify and understand the techniques that adversaries leverage most frequently.

2. Choose a habit that is as easy as possible to perform

Most security programs think “we need to test this stuff,” resulting in an annual red team engagement. An annual test is better than no test, to be certain. However, a few dozen atomic tests throughout the year are more immediate, less expensive, and substantially more impactful.

Action: Create a checklist of the places that are most important to review immediately following execution of the Atomic Red Team test

The purpose of this step is to make it as fast and repeatable as possible to determine whether the test resulted in any defensive telemetry, ranging from log entries to alerts to confirmation that the activity was blocked outright. For example:

  • Check log management for signals from the target endpoint or user
  • Review target system logs for related events
  • Check your Security Information and Event Management (SIEM) or log aggregator for alerts
  • Look through your endpoint protection dashboard for alerts
  • and so on . . .

It’s likely that you’ll build this list once, and evolve it over time. Even the act of identifying a new source of defensive telemetry that wasn’t initially identified can be considered an improvement.

3. Fit your habit into your routine

We’ve heard from hundreds of individuals and teams over the years about their approaches to testing with Atomic Red Team, and the teams that have done this most consistently have all made time and space for it as a part of their ongoing operational cadence. Some examples of where and how teams have fit atomic testing in their routine:

  • as part of weekly/monthly learning activities (i.e., “brown bag” learning sessions)
  • as a component of periodic purple team activities
  • as a part of periodic maintenance windows (this is crucial as pre- and post-change testing can help to find regressions)

Action: Set aside 30 minutes per week to perform a test

For some, setting aside 30 minutes every week might seem like a challenge. For those in highly operational roles, such as incident response, you might not have the luxury of guaranteeing any given block of time. If you find yourself in this situation, challenge your manager with finding and making the space for you to do this. Alternatively, ask your manager to do this themselves! It might seem as though this type of work is a “want” and not a necessity, but if you aspire to run a program that is mature and effective, it cannot be achieved without making time for readiness activities alongside reactive, operational work.

A free tool for tracking your test activity

What gets measured gets managed. In the interest of making it easier to document and measure your test coverage, results, and overall progress, you can use or adapt this Google Sheets template. For each test that you perform, capture whether you:

  1. Observed the activity: This could be a single system log entry indicative of the behavior or any other source of data that would make it possible to detect, investigate, or respond to the activity in the future. We cannot detect what we cannot see, so this visibility measure is particularly important.
  2. Detected the activity: Did any of your analytics or security tools alert you following the test? Did your managed service provider or other security partners notice anything malicious or suspicious? Note that most MITRE ATT&CK techniques are not malicious or even suspicious on their own, so detections should not be treated blindly as pass/fail criteria.
  3. Blocked the activity: For the subset of tests where the behavior or the technique has no redeeming quality (think “techniques indicative of Mimikatz”), or where you have analytics that are high confidence signals of adversary activity, was it blocked or otherwise prevented by one of your technical controls?

 

 

This is a very basic set of data points, and that’s intentional. By focusing on a limited, consistent set of data that can be used to measure test coverage and outcomes, we leave room for teams to perform tests using any mechanism that they choose. You can copy and paste an Atomic Red Team test into your terminal every Friday morning, or you can use something like Invoke-Atomic to schedule periodic, distributed tests of varying complexity at predictable or random intervals.

If you’re using this system, document template, or otherwise performing Atomic Red Team tests as part of your program, we’d love to hear from you! Email us at community@redcanary.com.

Additional resources

 

Emu-lation: Validating detections for SocGholish with Atomic Red Team

 

Emu-lation: Validating detection for Gootloader with Atomic Red Team

 

Safely validate executable file attributes with Atomic Test Harnesses

 

Find security bugs in web application routes with route-detect

Subscribe to our blog

 
 
Back to Top