Friday, March 31, 2017

From my Gartner Blog - Pentesting and Red Teams

My current research is a quick clarification paper about penetration testing, which obviously will include a discussion about red teams. I noticed during my research that there are a few general items that are generally used to differentiate between red teams and regular penetration testing. They are:

  • Objective: Some will say penetration tests are for finding vulnerabilities, while red team exercises are to test defense and response capabilities. I tend to disagree with this view, as I believe vulnerability assessments should be used if the primary goal is to find vulnerabilities, and I’ve seen (and had been part of) many pentests performed with the intent of testing defenses.
  • Scope and restrictions: Others will mention that pentests have well defined scopes, while red teams can “do anything”. I also disagree with this notion, as I’ve seen some quite unrestricted pentests and even red team exercises have some direction on focus and the methods to be used. The red team, on its continuing operation (more on this later, hold on), may have no restrictions or narrow scope, but each exercise is usually defined by a scope and objective.
  •  Point in time vs. continuing operation: Pentests are just point in time exercises, while red teams are continuous and run different exercises. Ok. Now I think we have something.

From those 3 points, I think only the third, the continuous operation, is a defining factor for a red team. The other two, IMO, can be seen as specific ways to run a pentest, or even just “high quality pentest”.

A red team should be a continuous operation to keep the blue team on its toes. With continuous operations the red team can pick opportunities and scenarios that best fit the threat landscape of the organization at each moment and also work together with the blue team to force it into a continuous improvement mode. This also answers a common question about when to implement a red team: continuous improvement is often a defining factor of the highest maturity level in any maturity scale. So, it makes sense to assemble a red team (a continuous one, not a single “red team exercise”, which is just another pentest) when you already on a reasonably high maturity and wants to move into the continuous improvement territory.

So, anyone out there strongly disagrees with this definition? If so, why?


The post Pentesting and Red Teams appeared first on Augusto Barros.

from Augusto Barros

1 comment:

  1. We have completed fucked it up in infosec.

    Red-Teaming Analysis is a way of thinking. It's an intelligence analysis technique. It's a method. You produce a list of threats, targets, and a list of equipment used by those threats that cause a calculable amount of damage to specific target types, such as structures, weapons, money, recruitment, et al.

    Penetration testing is supposed to inherent its roots from the intelligence analysis technique called Simulation. In Simulation, you test out theories using mathematics and statistics that show how a war or a series of battles would progress.

    Finally, I bring you to a deeper understanding of Vulnerability Assessment. This is where infosec completely goes off of the rails. A vuln assessment is a counter-deception technique that allows you to walk through the various D&D (denial & deception) TTPs in order to come up with strategies to counter them.

    We are really fucking idiots in infosec, aren't we?

    Allow me to put this a little more plainly as well. In pen test, you take Nmap and feed half of it to metasploitHelper and half of it to EyeWitness. Then you feed metasploitHelper to the metasploit-framework until you get a bunch of multi/exploit/handler modules to pop sessions and then you document it all with the commands: vulns -i, loot, and creds. You've also fed EyeWitness to Burp Suite Professional and gathered it all up into Dradis Pro to show your boss. He or she thinks your report is so pretty! Then he or she says to you, "Oh, look, you also did a vulnerability assessment, thank you!". And then 792 vulns get reported from BugCrowd in one day and 43 of them end up being true positives after you spend 4 months digging through that data and 7 years trying to remediate vulns.

    Alternatively, there are these things called red-team engagements. You download powershellempire and modify its C2 to look like malware or RAT C2. Then you modify the way that it affects filesystems, registries, and process or kernel memoryspaces in the exact ways that malware or RATs do. Then you find out which actors target your org by mapping MITRE ATTCK tactics and techniques. Then you emulate those actors with powershellempire in order to demonstrate that you live-response capabilities will detect (the hunting function) and successfully be able to open a takedown order with MarkMonitor (the killing function).