White Card Tracking

Tracking white cards during assessments

The project dashboard has a White Cards tab for tracking project white cards. Like the term deconflict, white cards come to us from the U.S. military. They refer to “a simulated event in an operational test.” A client may issue a white card for various reasons, such as if a system is too fragile or critical to risk attempting to exploit it or if there is a need or desire to bypass exploitation due to time constraints.

The latter may be the most common white card. Today, we commonly refer to assessments with this white card as “assumed breach.” With such a white card, the assessment begins as if the team has successfully exploited an external system or gained access or credentials through other means (e.g., phishing).

This white card and other simulated events must be documented and tracked. Each white card has a date and time the client issued it, a descriptive title or headline field, and a free-form field for more thorough or detailed descriptions.

Example of a White Card

These fields make it simple to include these in a Ghostwriter report template as a list or table of white cards.