I've been meaning to post something earlier than this about my experiences at the Illinois Cyber Defense Competition, but sometimes life gets in the way.  Participating on the Red Team has solidified some of my thinking on best practices in Information Security.

This is the first part of a series of posts I hope to write to share some of the experience. 

1.) Think strategically

The teams were given an hour to protect their networks before we started any attacks (network probing was allowed during this time).  After that hour was up we launched attacks using various tools including Core Impact.  Once we started attacking we were able to get system/root access on systems in every team network within minutes except for one (which was down due to router config problems).  What is significant about this is that we didn't have any back doors or other surprises - these were standing non-patched remote Windows (and in some cases, Linux) vulnerabilities that we were exploiting.

After the competition I had the opportunity to speak with some of the teams and I think what happened is that most teams spent that first hour trying to patch all of their systems, a nearly impossible task due to the lack of direct Internet access and the number of reboots involved.   Once the hour was up, the number and success of intrusions kept the teams off of balance for the remainder of the day.

I think a more strategic approach would be to start by installing firewalls and intrusion prevention systems on the network and on each of the hosts.  Initially for the network, the teams only had ACLs to work with, but they're better than nothing.  They also could have opted to repurpose a system as a "firewall on a stick" using VLANS off of the switch, which would have made our job VERY difficult.  For Windows systems a team could use the built in IPSec policy or a tool like Core Force (which includes a port of BSD's PF firewall).  On Linux systems, iptables would have done the job handily (especially if you set default deny rules in both the INPUT and OUTPUT chains).  This "virtual patching" could be followed up by real patching for defense in depth as the opportunity came up.

2.) Social engineering beats security awareness training

On the last day of the competition I launched a spear phishing attack against the blue teams in the form of an email that was formatted to appear from the white team.  This email puported to offer information on the next business inject (task) if they clicked a link.  The link led to a process running on the Core Impact box that would deliver a client side attack (setSlice was one of them).

Two teams clicked the link, and Core successfully installed an agent on one of them.  To make things worse, the team that we were successful against had clicked the link while logged in as Administrator on the team's Exchange server.

The lesson I took from this is that if an information systems (or security) student can be convinced, in the middle of a security competition, to click on an unknown link so can your users - no matter how much security awareness training they've had.

This isn't to say that security awareness isn't worthwhile.  If some social engineering and non-targeted attacks can be avoided with very little investment, awareness training was worth it.  However, system design should take into account that, when an email with the right wording comes along, they'll click the link.

[To be continued]