Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Tiger teams, originally a military security-testing concept, are now used to test computer security as well. Forming an attack/defend security exercise is a useful way to test security, as well as train employees. Here’s how to organize such an exercise, and some necessary rules to make it successful.
We’ll cover two different approaches. In both methods, a team or individuals are assigned to a computer, and they must defend it, while trying to attack the others at the same time. The term “tiger team” historically applies to the people who are attacking, but in the computer security-training universe, both sides are normally attacking and defending at the same time.
The first approach is structured such that if any team gains root access on another team’s computer they win, or gain a certain number of points. The alternative method allows for many compromises and only punishes a team when they lose control of their “flag.” The Capture the Flag method, combined with requirements to maintain certain services, is how defcon CTF works. For simplicity’s sake, it’s usually enough to simply say that a root compromise is a win, depending on how long of a contest is desired.
Requiring everyone to run a set of services is very important, regardless of whether or not points are awarded based on their availability. Anyone can defend a server that isn’t listening on any ports. The key is to make sure that everyone is required to host the same types of services, and the services need to remain available to the other players. Ideally, a diverse set of services will be run, such as a Web, FTP and mail servers.
Choosing the host operating system will determine the outcome of the exercise; so choose carefully. Some flavor of Linux will probably be used. Sometimes organizers will choose an old version of a popular distribution, for example Red Hat 7.2. If the motivation behind choosing this OS is that the participants aren’t very skilled and you’d like to make it easier, then this choice has some merit. Be careful, though, because using a blatantly insecure distribution of Linux has a drawback. People are both attacking and defending, and if they’re forced to use an old version of Red Hat, they may spend all their time focusing on the defending part of the game.
Likewise, if the skills of the players are above average, you may wish to force the OS version to make the defending portion of the game a bit more challenging. Some will say that when everyone is on the same playing field, an unfair advantage exists for the attackers. Knowing exactly what vulnerabilities exist on a server makes the game quicker, but also makes the defending part the first priority. If you, as an organizer, would like to see what happens when everyone runs the same OS, then consider running the exercise in two parts. For the first few days everyone can run the same OS, then they are allowed to reload with their OS of choice.
Once everyone has settled into their system they will begin attacking. The first thing most people will think of is to start a port scan to see what services are available. Then, for some reason, many people immediately start trying to disable their opponent. A very fine line exists between exploits and Denial of Service (DoS) attacks, and many people feel that the only way to defend is to cut off network access from an attacker.
Some ground rules are necessary, and herein lies the controversy. DoS attacks are definitely a security issue, everyone can agree. But in simulating a real-world attack/defend scenario, should DoS attacks be allowed? The usefulness of the exercise quickly diminishes when everyone just takes their neighbor off the network, so most of the time, no, DoS attacks aren’t permitted.
In some situations, for example when people are learning about networking, it can be instructive to allow network attacks. Flooding the switch to allow for a man-in-the-middle attack is certainly valid. That alone won’t knock your foe off the network, and it’s necessary for quite a few attacks. An example of “rude” attacks is broadcasting invalid ARP data so that the router can never talk to a host. This is a pure DoS attack, and it makes it impossible to attack or defend for other attacks: everyone just spins their wheels.
In the previous example, the obvious solution is to hardcode ARP entries in the router. Each team will also want a static ARP entry for the router, and the problem is solved. Again, it depends on the goals of the exercise. For learning about securing a computer from local subnet attacks, allowing some types of DoS attacks are useful. If that isn’t your intention, be sure to implement a no-DoS rule, or the entire time will be spent dealing with frustrated players.
Make sure that every player documents everything they do. When the exercise is over, there are always confused parties looking for answers. How did you get root? Why were you trying to attack port 119? A well-documented exercise is useful for review and for future training. In the true spirit of “tiger teams” the defended computers should probably be somewhat similar to the production servers the players are paid to admin on a daily basis. Setting up as realistic a scenario as possible can uncover some important security holes in your existing deployment.
Aside from the sheer enjoyment aspect inherent in this type of exercise, it’s also very educational. We’ve never met anyone who hasn’t learned something during a tiger team exercise, regardless of skill level.
