War Games: A WOPR of a Security Test (Part 2)

In part 1 of this series of posts, we covered what constituted a War Game and how we defined the various attack scenarios. In this part, we will cover our Cisco Security Advisory Services team used these scenarios to develop real world threat models and establish other parameters of the engagement.

Having defined the scenarios, you can see how these could be linked together in different ways to form comprehensive attack vectors. They also overlap sufficiently to give good coverage of blended scenarios. For instance, a complicit insider could knowingly open a malicious email that would introduce code that could then exfiltrate sensitive data.

All of these are handy scenarios of what could occur in a real world attack; however, they are quite useless unless we can establish what information an attacker would consider valuable, or what information they would require as input to other links in the chain. Some of the scenarios are a clear win or lose, or can be measured by some level of success.

Some of the target information an attacker may seek is fairly obvious – things such as administrative passwords or configuration files. Other data can be quite peculiar to the business sector or the business itself; therefore, as a team, we were careful to work with the client in order to identify these trophies prior to the engagement.

Establishing a win or lose threshold was a bit more straightforward for some of the scenarios, for instance, you can either elevate privileges on a laptop or you cannot. Clearly, there are various caveats that can be applied, such as the duration of access, socially engineering an administrator, and the race condition that usually exists between new exploits and patching, but so long as we are aware of those and can work within these parameters, it becomes fairly obvious if you can achieve certain goals when executing a scenario.

Some of the failure conditions were clear-cut, too: if we were detected or blocked, it was considered a failure. Failing, however, was not a straightforward “Game Over”; it meant we would continue the scenario, but would use alternate tactics, such as reducing the rate at which we would probe individual systems.

To put an additional spin on things, the client had quite a large building and had the capability of narrowing down network connections by floor, so one of the goals of the “defenders” was to not only identify an internal attack, but to walk up to us and “arrest” us. The attacking team would then be relocated to a different location, thereby making it a real “cat and mouse” game.

As can be imagined, putting together the scope for this engagement was as challenging as it was enjoyable. The next step for us was to then take into consideration all of the possible types of systems, and second guess what possible technical hurdles the attacking team would be confronted with in order to ensure that we could cover as many of the scenarios as thoroughly as possible.

Fortunately, we have quite a large and well-skilled team, so gathering troops with the requisite broad skills base was relatively easy.

We needed all of the usual suspects: UNIX, Windows, networking devices. We also needed a few wildcards – people who could develop bespoke tools at the drop of a hat, or who had the sort of devious mind that could target users via email in a way that would be irresistible.

More importantly, all of the team members needed to be able to work creatively, independently and yet still in concert with each other, sometimes under circumstances of limited communications.

With the merry band of War Gamers assembled, all that was left was for us to be granted entry to the client site – under assumed names naturally – and get to work.

In the next part of this series, we will cover how the engagement progressed, the technical obstacles that hindered us, and in some cases how security controls worked either for or against us.

Share