What is Internal Penetration Testing?

Sometimes companies wonder if it is possible to perform penetration testing internally rather than contracting the work out to other third-party companies. The answer to this question is that they can, but there are some things to consider here. One thing that should first be considered is the size of your organization and the maturity of your security program internally. If your organization is large and has the resources and already has a mature information security team internally, then this might be worth considering as an addition to the information security team.

Generally speaking, hiring staff that exists for conducting in-house penetration testing would be known as a “red team” in your security program. They are generally used for routine testing and security-oriented quality assurance. However, in most of the organizations that do run a red team, they generally do also consult with an external third-party vendor or multiple third-party vendors for penetration testing, and the red team is used as more of a supplement to this normal practice. Let’s look at some of the pros of what an internal red team can bring to the table for an organization.

Pro: Internal Red Teams can be Cost Effective

If your organization is large and has constant need for security assessments and security-oriented quality assurance, then it might be worth it to just add some of that talent to your organization’s head count. My own experience includes working for one such company as a member of a red team tasked with performing security evaluations of new third-party products under consideration or performing security-oriented quality assurance of products we were considering rolling to market. For this company, being as large as it is, with the volume of need for this sort of testing, it made sense to have full-time staff for this purpose.

Pro: Internal Red Teams are Extremely Flexible to Business Needs

Another advantage of having an internal red team is that they are on your payroll and you have full discretion over their policies and operation. This can also make them easier to deploy on odd jobs that generally fall outside of what most third-party penetration testing companies normally do. Being on the payroll, they are already bound to any internal non-disclosure agreements and non-competes and you control the vetting process of the testers. This can allow faster spin-ups of internal testing as there is no need for legal agreements to be signed and implemented if the tester and machines to be tested are both assets of the organization; you can jump right to testing.

Pro: Internal Red Teams Allow You to Keep Internal Secrets Completely Internal

Another instance of using internal testing I have seen is in cases where a company has an internal intellectual property or process where they absolutely aren’t willing to take risk on it becoming public knowledge. In cases like this, they want to keep it strictly internal and aren’t willing to consult with third-party vendors, even with non-disclosure agreements because of the confidentiality level of what they are working on. They want as few eyes to see the intellectual property as possible and at that point, they are more comfortable with the testing being done with their own staff that they vetted.

Pro: Red Teams can Lend Their Expertise to Blue Teams

Another advantage to having an internal red team is that they can help support the efforts of the blue team in the information security team. For the sake of being complete, a blue team would refer to the staff that focus solely on securing the assets. This usually includes ensuring systems are patched, policies are in place, monitoring IDS/IPS systems and logs, etc. The blue team’s focus is on ensuring that the organization is secure, with a defensive mindset. The red team focuses on the offensive mindset, like circumventing the controls in place to evaluate whether they are effective or not. While they are both security professionals, their skill sets are often vastly different. Having an internal red team can provide that offensive mindset as a knowledge resource to the blue team and help them with their objectives when they are outside of their skill set or need the viewpoint of how an attacker might look at something. When you have individuals, or teams working collaboratively on offensive and defensive security this is called purple teaming.

Now that we have listed some pros, let’s review some of the cons of running your own red team.

Con: Red Team Talent is Hard to Come By

Staffing a red team can be hard to do. This is a skill set that still has more demand than supply. As a result it can be hard to find good talent to staff the team with. If you do find them, the salaries are usually pretty high as well. If any of them leave the company, that spot could be vacant for a while when scouting new talent and result in a drop of bandwidth of the team.

Con: Developing Internal Guidelines for the Red Team

If you can find the talent, then you will also need to create guidelines for how it operates in the organization and effectively its mission statement in the organization. This also includes the testing methodology they will use in day-to-day operations. As someone who had to set this up, it’s actually a massive undertaking since it needs to be tailored to the exact need and expectations of the business.

Con: Bandwidth Limitations

While the cost can come down when running your own red team, I have seen time and time again where external third-party testing was needed supplementally to keep up with the workflow due to a fixed team size and fluctuating workloads, especially if it deals with testing products to be released and the organization starts running a large push for several new launches at the same time. When this occurs, you either need to accept launch or project delays, or outsource the work to a third party vendor. Either way it is something that needs consideration.

Con: Training Cost

Information security is a constantly evolving field. As a result, red team staff will require training to stay current on the latest security research and best practices. This is an additional cost that would need to be considered if you have an internal red team, both financially and from a time sink standpoint. This is present with most IT groups in an organization but the need is much higher with red teams as new attacks emerge. When using a third party vendor, this is their problem, not yours.

So Why Use External Testing If You Have an Internal Red Team?

As mentioned earlier, Internal red teams are usually supplemental to having external third-party testing. One of the main reasons is that some industries have compliance standards that require third-party testing, and even cycling through different vendors each year. We have a knowledge base article titled Should We Switch Vendors Annually? that covers this in more detail. Another common reason is that companies that have the size, resources, and security maturity to run a red team usually still like to have third-party testing performed to have a different set of eyes looking at it. The thought here being that different sets of eyes might catch something other sets missed. Finally, a lot of organizations this size may have work loads bigger than their red team can handle and are looking to outsource due to bandwidth issues as one-off jobs to keep project timeline in check. There is also the issue of optics, in that a third party tester will be less likely to have any bias regarding the success of a project. That objectiveness can prove useful if anyone asks “has your product been tested for security concerns” that you can show a letter of attestation from a third party with no horse in the race as opposed to saying “Yes, we tested it ourselves and found it to be secure”, which might lead the asking party to wonder if that is trustworthy given the conflict of interest.

Generally, companies with red teams still generally use third party testing alongside their own red teams. Both carry their own set of benefits and if you have the resources to do both, you absolutely should. If not then it would be better to just use consultants that are security experts as needed and set up a vulnerability management program and policies to ensure that findings are addressed and a baseline of security is established.