Policies – principles, rules, and standards

Your organization probably already has policies around security testing in place, although probably in a different manner than you would expect. At the beginning stage, any form of penetration testing is most likely explicitly disallowed! To enable offensive security engineering, it's necessary to augment these rules and standards to provide a framework for the offensive team to perform its duties.

Policies and standards are also there to protect the offensive security team to ensure the team is working within an established and authorized set of policies. As the manager of the program, you should also ensure that everyone that carries out such activities has read and agreed to follow these rules. Again, there might already be an established process in your organization. If not, find yourself a way to track it.

Principles to guide and rules to follow

Penetration testing and offensive security are some of the most exciting tasks to work on. It's a job that requires skill, creativity, curiosity, and dedication.

To get the most out of an offensive security program, it's important to define a set of principles that highlight the values and goals of the offensive security team. These principles are there to guide you when you encounter unknown territory, and offensive security engineers deal with such situations on a regular basis.

Acting with purpose and being humble

After years of being a penetration tester and offensive security engineering manager, leading large operations with dozens of stakeholders, some pieces of advice I would offer to help you have a meaningful , positive impact is to have fun, be humble, and be encouraging.

Avoid getting defensive or arrogant, since in the end you are on the offensive side, the side with power, the side that can drive and lead the change. Be there to ignite that change for your organization and inspire the organization to understand and embrace alternate views and vulnerabilities. Encourage them to even help you find variants of issues. Consider adjusting your own views to alternate viewpoints. Always assume that there is something you do not know.

Penetration testing is representative and not comprehensive

Testing is never finished. Security and penetration testing are no exception to this. There is always going to be another bug that can be found by applying more resources. The core responsibility is to invest and perform due diligence so that the most significant risks are uncovered.

Pentesting is not a substitute for functional security testing

The least desirable outcome of a penetration test is to find vulnerabilities that are clearly functional security issues, such as a lack of authorization or incorrect authorization behavior.

A boundary should be drawn by the offensive security team to set expectations around software quality first. That's why measuring the results of penetration tests per component or service team can be quite powerful, because data over time might show that certain teams in the organization demonstrate certain patterns. These teams might benefit from additional training or additional design review or quality assurance measures before engaging the offensive security team.

Letting pen testers explore

Penetration testers need independence and not to have to do what others want them to do. A lot of exceptional test engineers and red teamers act based upon intuition and gut feeling. This is not something you want to prevent or block. The overarching rules and principles are there to enable and protect this behavior and to hold all stakeholders accountable.

Informing risk management

One final principle to give to the team is that their goal is to help inform the business owners about business risks. What are the scenarios that can harm the business the most? The offensive security team is there to highlight them, remove uncertainty about the existence of issues, and improve understanding of the risks while reducing the probability of those risks occurring.