<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1678611822423757&amp;ev=PageView&amp;noscript=1">
Defrag This

| Read. Reflect. Reboot.

Setting Up Red and Blue security teams

Missy Januszko| September 27 2017

| IT insights

Defending against new threats is a never-ending battle, and in that battle, regular penetration testing becomes a great weapon in a security team’s arsenal.

Devastating malware such as WannaCry and Petya taught IT organizations all over the world valuable lessons this year. Organizations with strong security testing infrastructures learned firsthand the things that they did well by keeping the malware from affecting their businesses. Those with mediocre security infrastructures, notably the ones that still managed to keep the malware from affecting them, learned two lessons – the strengths of the pieces that kept the malware out, but they likely also learned about where to reinforce the infrastructure to keep out future attacks. 

The organizations with poor infrastructures suffered the most, as they learned firsthand where their major vulnerabilities were located that caused the security breach. But organizations with mediocre or lacking infrastructures should not be waiting for a vulnerability to come out to learn these lessons. 

Related: Defrag This - WannaCry

The Benefits of Penetration Testing

Regular penetration testing provides not only important technical information back to the security team responsible for the security infrastructure, but it also provides valuable benefits to the entire business. If your business relies on the availability of your IT infrastructure and systems, the first benefit of penetration testing is simply being able to keep the systems up – and the business running – during a malware event. 

Identifying and rectifying potential vulnerabilities before they happen not only prevents devastating events during a malware attack, but it also preserves your organization’s image during such an attack. Second, penetration testing provides valuable information about where your infrastructure may be weak to keep out future vulnerabilities. Lastly, regular penetration testing can help your organization demonstrate regulatory compliance as well.

Related: Pen Testing 101

Building a Pen Testing Team

A realistic penetration test will be comprised of both offensive and defensive tactics, as those actions both take place during a real malware attack. The malware itself is offensive – meaning that it will attempt to penetrate the network, possibly gathering information about the network itself, gathering credentials, exploring for valuable data, and doing something with the information it gathers – stealing the data, or perhaps destroying it. 

A “red team”, or offensive team, probes for vulnerabilities and attempts to penetrate the network just like a hacker would. Your security team defends against the malware as the “blue team”, using defined controls to detect the intrusion and thwart its efforts to compromise the network and the data.

Red-Teaming and Blue-Teaming – Military History

setting-up-red-and-blue-security-teams.jpgRunning simulations of offensive and defensive strategies isn’t a new concept. After all, many sports use this concept – one team is on the offensive and attempts to move the ball/object through the defense to score.  However, red-team-blue-team exercises originate from military exercises. 

The red team, or bad guys, use creativity and cunning – maybe even unethical methods - to attempt to penetrate the defensive efforts of the blue team. In penetration testing, the red team has two major goals – not only to penetrate a blue team’s defenses, but to provide information back into to the planning and operations on how to defend against or prevent the attacks. 

The blue team’s objective is to mature the infrastructure as the exercises persist. For example, an operations team detecting an attack meets the objectives of such a vulnerability assessment, but having automation in place to detect, alert, and remediate is even better. 

Conflicting Characteristics of a Red-Teamer

The red team is comprised of “potential” bad guys – but potential bad guys that your organization has hired. Keep in mind when hiring a red teamer that he or she will have unusual characteristics that, at times, conflict with each other. Red teams can be comprised of internal employees or external consultants. They needs to have a “bad-guy” mindset – not only from a technology perspective, but the exercise may require a red-teamer to perform unethical procedures such as stealing keys, breaking or sneaking into a building, and stealing credentials. 

The conflict occurs because not only does he need to have the cunning needed to get away with these things, but he also needs to have a high ethical code to keep information discovered private and not exploit information for his own gain.  There is a possibility that during an exercise he or she will gain access to valuable information about vulnerabilities in the network, or gain access to passwords or data. For that reason, you must be able to trust a red-teamer with this highly sensitive information. 

Additional Dangers of Red-Teamers

In addition to the information that a red-teamer could potentially access, penetration testing has the potential to damage a business during the test – by damaging systems or data – so the red-teamers need to perform their duties without causing harm – and identify when an exercise should stop before real damage occurs.

When hiring an external team to perform such testing, consider a firm’s reputation and the proper documents – non-disclosure agreements and other documents your legal team requires – get signed prior to testing.  Don’t allow your pen testing team to become a real attack – research and vet potential testing companies to ensure they have the ethical hacking standards your company requires.

Red-Team Tools

Permit your red team to use whatever testing tools they feel they need to execute a realistic simulation.  Whitelisting tools doesn’t permit a realistic simulation, after all, stopping an attack won’t occur in the real world by security policy alone.  If your organization doesn’t allow a certain program or tool, your blue team should be detecting and alerting on that tool and preventing its further use. The red team should be constantly learning about new threats, vulnerabilities, and tools, and incorporating newly-identified information into their tests.

Do You Need a Blue Team?

The maturity of your security tools, organization, and infrastructure will determine the need for a blue team.  If your team already relies on automatic detection and remediation of threats and doesn’t employ a regular team providing a second set of eyes on the security infrastructure, then a blue team for the exercise may not be necessary. 

Since you don’t know when an attack might occur, having a blue team that is “business as usual” will provide valuable information about your organization’s effectiveness in preventing an attack.  If your business as usual includes an operations team monitoring the infrastructure, then this team is part of your blue team, as well as anyone your operations team may alert or involve when detecting suspicious activity. 

Your blue team should also include anyone tasked with remediating the findings of the pen test, although the actual test may not need to include those folks. Your red team may also be part of your blue team once the exercise is over, as they can make recommendations to defend against the attacks they used.

Try WhatsUp Gold Free for 30 Days   See how easy Ipswitch makes network and flow monitoring with a 30 day trial of  WhatsUp Gold.   30-Day Free TrialBlue-Team Tools

The blue team should identify the controls available to them during an attack or a simulation.  These commonly include anti-virus or anti-malware applications, SIEM (Security Information and Event Management) tools, monitoring alerts on firewalls, operating system auditing, intrusion prevention and detection systems, etc.  They should also already have identified the responses to each that would take place when an attack is detected as part of an incident response policy.  Blue-teamers may also be identifying other controls or tools during or after a penetration test, and any new controls identified get fed back into the incident response policy.

End Results

Penetration testing provides valuable information as well as skills for both teams.  If the red team is internal, they get to exercise their creativity in figuring out how they would exploit the system infrastructure for money or fame. They get the benefit of playing a bad guy without being an actual bad guy. They also get to identify which attacks worked and which didn’t, and then work with the blue team to adjust their controls to block the attack. 

The blue team gets valuable information about which parts of their incident response policy worked well, and which ones need some work to block potential attacks. Their job doesn’t end after the test, since they’ll need to make changes to remediate the findings of the vulnerability assessment.

The real winner, however, is the organization – because their infrastructure will continually become more resistant to threats, but defending against new threats is a never-ending battle, and in that battle, regular penetration testing becomes a great weapon in a security team’s arsenal.

Topics: IT insights

Leave a Reply

Your email address will not be published. Required fields are marked *

THIS POST WAS WRITTEN BY Missy Januszko

Missy Januszko is an independent IT consultant, with more than 20 years of experience as an enterprise hosting architect, large-scale infrastructure designer, and hosted application designer. She specializes in DevOps, automation and configuration management, PowerShell, and Active Directory, and has broad experience across the entire line of Microsoft business technologies. Missy is a co-author of “The DSC Book” with Microsoft MVP Don Jones, and she is also a conference speaker on DSC-related topics. She is a contributor to a number of open-source projects, including “Tug”, the open-source DSC pull server, and “Autolab”, an automated, rapid-install lab build.

Free Trials

Getting started has never been easier. Download a trial today.

Download Free Trials

Contact Us

Let us know how we can help you. Focus on what matters. 

Send us a note

Subscribe to our Blog

Let’s stay in touch! Register to receive our blog updates.