At a high level, one of the best ways to look at a red team is to consider it the devil's advocate. The vision is to ensure alternative views are considered and that stakeholders are held accountable. The program is there to provide reality checks at times of forming a consensus. This is done by demonstrating not just the theoretical but the real-world impact of exploiting weaknesses and informing the organization's risk management process and leadership.

In many ways, an offensive program fulfills a security testing function within the organization, a sometimes rare but much-needed function in the modern world of software engineering, full-stack development, and DevOps.

To run an effective internal offensive security program, a simple yet inspiring mission to help communicate the purpose and motivate the team is important. The mission should be about what is being done, there is no reason to dive into how something...

To run a successful red team program, it is critical to have active leadership support.

One of the big benefits of an offensive security program and red teaming generally is that they are there to keep everyone honest. Trust but verify. The support of the Chief Security Officer (CSO) is probably easy to get, but the support must be beyond that; it must include the other executive levels of the organization as well. This can't be stressed enough; if you do not have executive buy-in, the effectiveness and outcomes of the program will be limited. Getting long term buy-in might be achieved by using various strategies, including providing data and providing actual breach results, explaining how they impact the organization.

Convincing leadership with data

When looking at data, it is useful to look at the competitive landscape and analyze recent breaches that have occurred in the industry, and the associated impact they have had on organizations...

Initially, I would not spend too much time thinking about where in the organization the offensive security team should be located. If you are just starting out, it's most likely that only one full-time person is tasked with offensive security work. The more critical part at that stage is to get executive sign-off and support to perform offensive testing and deliver results. The bias should be toward action at first and to demonstrate a positive impact. In some organizations, the program is entirely outsourced, and only logistics are driven internally, although typically the desire to build an internal team will grow.

A typical organization structure will probably put the offensive security team in either the defense and response part of the company or as a function of a Security Assurance team. I have also seen offensive security teams being put in legal and compliance areas of companies. A lot of this depends on the size and structure...

When it comes to successfully managing an offensive security program, it's critical to define an overall roadmap that acts as a foundation and guidance going forward. Think of a high-level plan for the next two or three years. Most likely the program will grow organically if the initial investments are fruitful and the return on investment is made visible. This is what I have observed across different organizations that have implemented an internal offensive security program. In the beginning, start out small, and one or two years later it grows into an actual team of full-time employees. Overall, there are possibly two options initially. One is to build a program and a team from scratch, and the other one is to use already existing resources that can be leveraged.

Building a new program from scratch

If you are starting out from scratch it might seem rather intimidating, but it's also a great opportunity. The most likely scenario...

A useful way to look at an offensive security program is that it is providing services to the organization. If the reader is familiar with red teams that focus on business processes or other aspects of an organization, this topic is primarily focused on the cybersecurity angle.

Providing service offerings means that other business groups, blue teams, and employees are our customers, so to speak. The modes of operation, responsibilities, and tasks of the penetration test team can differ quite a bit depending on what the scope and responsibilities are. It might or might not include design-level work and reviews such as threat modeling, but it certainly should include hands-on offensive penetration test work and finding and exploiting vulnerabilities for defensive purposes. Most of these services revolve around alternative analyses.

The following subsections are a list of services a penetration test team might provide to its customers...

So far, we have pointed out some of the core tasks that a red team program will be carrying out. There are additional responsibilities that should be looked at and possibly be integrated into the program. Let's look at some of them in more detail.

Security education and training

The offensive security team can help change the culture of an organization and help improve the overall security IQ. As a part of operations, pen testers learn a lot about the people, processes, and technologies of the organization. The offensive team is also in a powerful position to ignite cultural change and help the organization improve its unique understanding of security.

Increasing the security IQ of the organization

In tandem with education and providing training, the job of the offensive program should be to improve the security IQ of the entire organization, including blue teams, service and product teams, human resources, and finance...

This aspect is commonly under-invested into organizations. To build a strong offensive security program and attract talent, it's critical to have a clear path of education for team members to evolve both individual career aspirations and the program itself. This includes being able to attend security conferences to learn and network, but also to present their own research and get inspired by the work of others to come up with the next great idea or operation.

It's not uncommon to get stuck in continuous operational work and to forget about training. There is a great analogy a mentor once told me. As far as I know, the story is based on something Abraham Lincoln said.

There is a woodcutter who cuts wood all day long. Over the course of time, his ax loses its sharpness. He gradually becomes slower and slower at cutting wood. He is just too busy cutting wood to sharpen his ax! One day, a friend tells him, Hey man, I...

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...

A set of clear rules of engagement should be established and approved by leadership and the legal department to ensure that tools, techniques, and procedures can be applied to simulate and emulate adversaries effectively. A superior penetration testing team holds itself accountable to the highest possible standard and works with excellence. This includes business ethics.

Therefore, it's important to establish rules that the team follows. Some examples are as follows:

• Do good! Always operate with due diligence.
• Do not perform denial-of-service testing or deny access to systems intentionally without explicit authorization.
• Consult the no-strike list before compromising assets. (A no-strike list is a set of assets or systems that are off-limits to the pen test team.)
• Operate surgically, rather than carpet bombing targets.
• Handle credentials and other sensitive security artifacts securely and safely during and after the conclusion of...

A standard operating procedure (SOP) describing the overall workflow of how a penetration test or offensive security operation is created. It includes involved stakeholders, approvers, informed parties, other participants, and the objectives of the operations. An SOP is important in ensuring that a mature and repeatable process develops. Like the rules of engagement, it's advisable to seek legal counsel to ensure that the tactics and techniques highlighted do not violate company policy or laws.

There are considerations throughout an engagement, and procedures might vary depending on the service offering that the procedure discusses. The following diagram shows some of the possible cornerstones of a purple team service. The many stages and procedures are also present for red teams and penetration testing services.

It is useful to templatize the SOP in order to have a repeatable process so that the format can be reused:

One of the core responsibilities of an offensive security team is to strategically model adversaries and threats that the organization faces. The program should be a direct contributor to the risk management process. At a high level, one might distinguish between external and internal adversaries, although the majority of the likely objectives for malicious activities have some form of external motivation. For instance, an internal employee might be blackmailed by a government agency to exfiltrate records from the customer databases. Even though this is seen as classic insider activity, the actual entity behind the scheme is external.

Understanding external adversaries

This is an actor or threat that originates and operates entirely from the outside of an organization. A typical example is a script kiddie or a nation-state that attempts to breach the perimeter of the organization. This adversary will focus on the attack surface of the organization, which...

There are a set of frameworks available that describe the typical progression of an adversary when compromising assets. There is, for instance, the Lockheed Martin Kill-Chain, which is quite popular (https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf).

Over the years, more refined and generic frameworks have also been established, such as the MITRE ATT&CK framework (https://attack.mitre.org), or the Unified Kill Chain (https://www.csacademy.nl/images/scripties/2018/Paul-Pols---The-Unified-Kill-Chain.pdf).

The kill chain as defined by Lockheed Martin does have some limitations and only models a subset of adversaries. Later in the book we will do a more in-depth analysis and see how these frameworks can help you build strategies for your operations and cyber defense.

Not following any of these frameworks in particular, let's discuss the anatomy of a possible breach that a red team...

When performing operational red teaming, there are two basic approaches when it comes to compromising assets. The first one is to be very targeted and surgical, and the second one is to perform large-scale assessments and exploit attempts. Surprisingly, the second one often leads to a much better understanding of the environment and discovering unknowns. Let's explore this in a bit more detail.

Surgical

A surgical operation typically requires more detailed planning and reconnaissance. This is a good approach when there are clear objectives being set as part of the operation. The goal is to stay under the radar for the entirety of the operation. A surgical approach could, for instance, be as targeted as sending a phishing mail to two or three people and navigating into the victim's inbox to retrieve access to sensitive email or stealing critical business information from the computers of the target.

Carpet bombing...

You might wonder why I would put an extra section that talks about the work environment and office space. I have found this to be an extremely crucial aspect of security across the industry, especially among software engineers. Many of us now work in open offices and shared environments.

These days, everyone likes open offices; at least, that is what management is telling us. Rather than diving into what this means for software developers who also deal with sensitive information and intellectual property, let's discuss what this means for security engineers, particularly for security engineers who deal with clear text passwords of systems and other employees, as well as potential information about unpatched vulnerabilities and so forth.

Open office versus closed office space

Personally, I'm not a big supporter of open offices, although for pen testing, an open office does work surprisingly well, with one caveat: ensure that only pen...

In this first chapter, we explored the foundations of how to build a successful pen test program within your organization. This includes ways to influence leadership to support an offensive security program and defining a clear mission to bootstrap efforts. We discussed the services a red team can provide to the organization and what it takes to establish an offensive security program within your organization.

To safely and securely operate, we highlighted the creation of rules of engagement and SOPs.

Furthermore, we learned about the basics of what adversaries your organizations might be facing and how systems get breached, and some tips to convey that information to other stakeholders.

In the next chapter, we will explore how to manage and grow a red team, and how to further develop the overall program to improve its maturity.