Creating a Red Team Program

Creating an internal red team, or penetration testing, program can be a daunting challenge, but the benefits of fostering internal testing capability are numerous and self-evident. Most companies rely on annual external testing to highlight major vulnerabilities or to reveal potential weaknesses in their cybersecurity posture. While useful, this point in time approach doesn't address the ongoing, and evolving, cybersecurity and vulnerability landscape. Furthermore, internal security teams can have distinct insights into the corporate landscape the external testers may never discover. Penetration testing can address all of these considerations and provide a unique training opportunity for internal cybersecurity team members. Access to training and professional development is a key component of moral and retention and fostering internal red team capabilities can be a significant, and popular, addition to your internal training opportunities.

The first step in establishing an internal red team capability is governance. While this is probably the least exciting component of setting up a program, it is critical in order to ensure consistency, risk reduction, and value. Your program governance should include a policy document that lays out roles and responsibilities as well as expectations. Inevitably your red team program will become popular and it will be important to advertise the scope, scale, and intent of the program as well as any resource or budgetary requirements. One useful strategy is to scope out a program with progressive levels of investment so you can demonstrate to leadership what can be achieved with no investment, a small investment, and a major investment. For instance, if you run an exercise that is valuable and highly visible you may be asked to run larger or more complex tests that could require additional investment and you can quickly point to governance to demonstrate how that investment will come into play (think of resources like dedicated testing machines, licensing specialized tools, training for testing, or even budget for additional headcount).

Your governance documentation should include several key details about your program. The first should be the pace of testing. I recommend setting modest goals with respect to frequency. You can always run more tests if you're able, but especially with a program that is going to be layered into an existing security team it will become difficult to predict the pace of other priorities and the availability of time. Because penetration testing is fun and challenging you'll find that people on the cybersecurity team will generally make time to work on testing, even if it requires additional effort.

Documentation is another key consideration of any testing. Governance should define how reporting will work and if possible you should create a report template (or search for one online). This should include a schedule of activities where specific testing windows are identified, the exact tests to be run during the schedule so that you can advertise the testing and hopefully avoid or identify any interruptions or service degradation during the testing. This schedule can also serve as a "get out of jail" card if there is any incidental incidents during the testing. It will be much easier to defend testing against suspicion of harm if you can point to a schedule that defines exactly what was done, when, and by whom.

Tests should always include a proposal to leadership before the test. In addition to being a great opportunity to give your tests clever names, this is also an important chance to advertise your program and get explicit permission for the testing. Especially if you intend to run tests that could contravene policy (for instance guessing passwords or leveraging another employees credentials) you need to have a pre-authorization from leadership. You should also include a communications plan in your proposal. This should identify parties to contact during the testing in case of any accidental disruption or to confirm whether or not any activity observed is related to testing. Even if you don't intend to warn your Security Operations Center (SOC) about testing you should let them know whom to contact if they suspect activity they detect could be authorized testing. Don't forget to include a clause in the proposal for adverse findings such as a critical vulnerability. Be sure to emphasize that testing will be paused to address any such finding. Finally, be sure to address priority in your proposal. For instance, if your security team has other responsibilities as part of their work be sure to call that out explicitly in your proposal with language like "testing is a secondary priority and will be paused in the event other responsibilities arise."

Proposals should also address scope, especially in terms of anything that should not be tested or interacted with. For instance, if you have any fragile or critical systems in your environment the proposal should address those regardless of scope. Your scoping section should lay out any boundaries or exclusions for testing as well as identify the target of the tests.

For your testing subject you can take any number of approaches. Open testing might include a testing target, such as an administrative account or system access, but might not specify exactly how that goal will be achieved. While this can give testers a lot of latitude in terms of how they achieve their goals, it can also be beneficial to state the exact routes of testing, or to test various stages of the cyber kill chain distinctly. For instance, in your internal testing you might want to assume an attacker has achieved initial access and only test lateral movement or persistence techniques. Just as with scheduling it can be helpful to limit your testing to ensure it is more achievable, especially as you are starting your program.

Training is often one of the most time-consuming and unpredictable parts of a red team, but the investment is hugely valuable as it offers opportunities for professional development and also demonstrates commitment to the team. Figuring out how to run testing can take a long time due to unexpected issues and challenges, especially if you're starting a program with little or no budget. Getting testing tools installed and working can take a lot longer than you might realize but are also opportunities for learning and growth. At a minimum you'll probably want virtual machines running Kali Linux for your testing team. Having a dedicated virtual environment for testing is useful for consistency and isolation, especially if testing could access confidential data. Kali Linux is a broad standard for penetration testing and lots of free documentation and training exists and can be used by your team. A more mature program might achieve a level of investment capable of supporting advanced commercial training such training is not necessarily a prerequisite to founding a program.

Testing reports are probably one of the most critical, but time consuming, components of testing. A formal report template should be developed that includes things like a priority algorithm for ranking findings and for recommending mitigations. Using a simple traffic light coloring scheme for findings can help to highlight the most important components of the report. While internal reports and findings may necessitate additional investment from IT teams to address risks, doing internal testing will typically mean a much more relaxed pace of urgency in addressing findings over an externally contracted penetration test or an audit. Being able to prioritize fixes in a way that is conducive to other ongoing internal development is one of the main advantages of supporting an internal team.

Be sure to provide final reports and any metrics associated with testing to leadership. This can be high level, but it is an invaluable demonstration of the value of investment in the program, even if that investment is just the team's time.