Example Security Exercises

The following is a list of security exercises you can try after reading Susan Sons' article "Security Exercises".

1) It's Gone

Pick a system, any system. Think of a reason why it's completely hosed—failure of the entire RAID array, fire in the data center, evil script kiddies, sysadmin mistake—and see how your team copes. Some questions to ask when all is done:

  • If you don't have another of these systems to fail over to, where are your users going while the system is down? What stopped working and for how long?

  • If you have a failover system, how long did it take to fail over? What did your users experience in the meantime?

  • How hard was it to replace the system? Were backups adequate? Did the available personnel know what to do and have the authority to do it?

  • What data was lost? Are backups being made often enough?

  • Were any other systems impacted by this system's death? For example, if your LDAP server died suddenly, did administrators still have access to other systems? Did anything fail open?

2) Naughty Ned

Choose a team member with elevated privileges (any member of your security or systems administration/ops team is usually a good choice, so might be a leadership team member or a developer). Pretend he or she has been fired, and revoke all of his or her privileges. Now he or she gets to cause whatever chaos he or she can with any privileges that remain. This is a great way to test your off-boarding checklist.

3) Wolf in Sheep's Clothing

Most of the Red Team plays the part of ordinary users here. One plays a malicious user. Can the Blue Team terminate the malicious user's activity without negatively impacting any of the nice users?

4) Committer Should Be Committed

This is a great one for software development teams. A developer, working while sleep-deprived (thank you Red Team), has committed something to the master branch of the repo that he or she shouldn't have. It might have been login credentials for an internal system or naked pictures of the boss' dog—the content doesn't matter. The important thing is that it has to go.

See how your team removes the offending data both from the working tree and the repository history, without breaking everyone's workflow beyond recognition.

5) Operation!

If you run a DevOps environment, this one's for you. It's far too easy for deployment workflows to end up with very low bus factors (the number of people who must be hit by a bus before the project is doomed or at least in serious trouble). Watch a deployment or two and figure out who the 1–3 most critical people are in that path, then declare them unreachable for the purpose of the exercise.

Now, suppose that a critical security vulnerability has been found in your deployed product. Challenge your team to make a trivial code change (for example, add a comment saying "We did it!" to the code at a specified point), then run your entire test suite and deploy the code with those critical people gone.

6) Finger in the Dam

Find a (hopefully fairly harmless) proof-of-concept for the most recent security vulnerability for which you applied patches. Run it against everything and find out whether the hole really was plugged.

7) Negative Nancy

Have a Red Team member contact your primary customer support avenue, playing the part of a user who is absolutely certain that his or her private information entrusted to your service has been compromised. Bonus points if the character is a "difficult" personality. See how the team handles it.

8) Fell Off a Truck

Your primary authentication database has fallen off a truck (your choice whether this is your database of external user accounts or something for internal personnel only). Demonstrate how you would notify those affected and force password resets. Bonus points if you can detect and flag attempts to use compromised credentials.

9) Ewe Did It

Start an (otherwise innocuous) process on one of your systems that occupies as much RAM as it can get its hands on. See how long it takes for anyone to notice, and how they respond.