The road ahead for offensive security

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 in this case is that you will have a one-person show initially, and by demonstrating its value and business impact, the team will start growing organically. It might also be the case that you entirely depend on external expertise initially, so you must hire vendors to fulfill the mission.

Inheriting an existing program

If you are taking over an existing team or are going through a reorganization in your organization that establishes or consolidates teams, there are some other unique challenges that you will face. I hope that many of the things highlighted about people and program management when it comes to offensive security engineering will help you as well.

To set a roadmap, it's important to first understand the maturity of an already existing program and team. Here are some questions to ask when taking over an existing team:

• Are the processes and documents in place already?
• Are the rules of engagement and standard operating procedures defined?
• Are there any test plans?
• What is the size of the team?
• Are the findings tracked and reviewed?
• Are the stakeholders and responsibilities clearly defined?

If you are just starting out, defining and creating some of these guidelines and rules is an important step since most likely your organization does not allow any form of offensive testing or intrusion. It can be the opposite: it's a terminable offense in many companies to compromise other machines or gain access to certain assets. Go off and read your employer's employee handbook. In order to make sure you have all the basics covered, this chapter describes some guiding principles and documents that you need to think of. Hopefully some of the content is useful and will help you enable penetration testing in your organization. Make sure to review any such documents and planned activities with legal counsel and other key stakeholders in your organization before engaging in penetration testing.

If you are inheriting an existing team, look at the capability maturity model for testing and how you can apply something similar for penetration testing and red teaming. This is described in more detail later in the book, when we talk about measuring the program.

In the following chapters, we will go over some of the basics to help bootstrap a program and have a basic roadmap in place. So, let's get to it.

People – meeting the red team crew

The most important component of implementing a successful offensive security program is retaining and hiring the right people that can fulfill its mission. Whether you are only starting out with a single penetration tester or you've inherited a larger team of already established offensive security engineers, it is the individuals who make the difference. Shaping the program by retaining and hiring the right people is of the utmost importance.

Penetration testers and why they are so awesome!

Throughout my career, I have always thought that testers are awesome. That's why I personally always liked the term "penetration tester" a lot, because it does highlight the testing aspect. This is not necessarily an opinion everyone shares. I have had the pleasure of working with and meeting some of the smartest individuals in the fields of security and offensive security. Many of them are professional testers, consultants, researchers, engineers, or penetration testers that have worked for large corporations with up to 100,000 employees, as well as smaller companies and security enthusiasts and students.

The one thing that always stands out among security engineers is the passion for security they project. They often have an idealistic drive to make the world a better place, as well as the passion to find issues and break systems. If someone is happy when they can break something and are excited to share the news, it's a good sign the person is on the right track to becoming a penetration tester.

The breaker mentality and a curiosity about how things work under the covers are greatly needed, especially in a time when organizations have moved away from employing dedicated test teams. The penetration tester is here as the spearhead to help keep an organization honest about the quality of what is being produced.

In many organizations, they are the last dedicated testers that remain. And the results they uncover are often not pretty, but much needed. On top of that, they are skilled, smart, creative, unique, and typically very fun to work with.

Offensive security engineering as a professional discipline

Some organization do not distinguish software engineering from security engineering. In the grand scheme of things, it all falls under the umbrella of general software engineering, and this, dear reader, is a big mistake. It is important to highlight the unique and distinct skillset of security engineers, especially those working in the offensive field. And what better way is there to appreciate their unique skillset than by calling them what they are, or even better, letting them pick their own title? Devil's Advocate, Security Engineer, Pen Tester, Red Teamer, Offensive Security Engineer, Adversarial Engineer, Security Ninja – why not?

This goes along the same lines as ensuring that the compensation for security engineers is evaluated in a distinct fashion from those of software engineers and developers. Reach out to your HR department to get an understanding of how your organization sees the roles of security engineers. Is there any precedent for offensive security engineers already present?

Strategic red teamers

Red teams, as well as penetration testing in general, is a technical and sometimes very tactical role. A way to grow is to embrace more strategic and analytical objectives and tactics – keep that in mind when building out the team. As soon as a certain level of maturity is reached, your organization will benefit from exercises that cannot be put into a box and are beyond typical network assessments, for instance. The red team will evolve into a group that always pushes the boundaries – at that point, there are no handbooks or playbooks to follow, besides a rough framework, and even that should be challenged.

Important Note

A red team that has never been tested and assessed by another red team is most likely not a mature red team.

There's more later in the chapter about maturing the offensive security program and the illusion of control.

Program management

Depending on the size of the red team and the complexity of the program, it might make sense to add program management resources to the team. The program management team can focus on maintaining the rhythm of the business by running regular sync and triage meetings. This is especially helpful when the program matures and collaboration with other stakeholders across the organization is necessary, including driving the rhythm of the business, as well as helping to integrate with risk management processes.

Attracting and retaining talent

Many organizations do already possess some ad hoc security testing capabilities, often performed by individuals who work on threat modeling jumping in to help with some hands-on testing.

Being a devil's advocate is something that might appear intrinsic and unlearnable or unteachable. Great pen testers ask a lot of questions. They always have a (some times annoying) but, what if? mentality. It's a very healthy attitude, especially for well-established organizations with long traditions of following the process, which might have been optimized and matured into a groupthink mentality.

When interviewing candidates for offensive security roles, stop asking unrelated or unnecessarily difficult coding questions – it's counterproductive. You are most likely not looking for a system engineer that can carve out the fastest and most memory-efficient solution to move subtrees around and sort nodes while keeping the tree perfectly balanced at the same time. Just stop it. If you focus on this, you will not find the person you need.

It's certainly okay to dive into coding questions that explore the candidate's basic coding skills. Unfortunately, in my experience, some organizations treat hiring offensive security engineers along the same lines as hiring a software developer. The skillset you are looking for is very different. Of course, finding a security engineer who is an outstanding coder and program manager at the same time would be amazing, but if you are only looking for coding and algorithmic skills you might miss the best candidates.

Some good questions should always be around problem-solving and how to break things. Let them break something they might not even be familiar with. The likely outcome of interviewing an outstanding candidate is that they will find a new or different way to break something.

Developing a consistent way of asking questions, so you can compare the candidates well, is also something to think of before starting the interview process. For technical issues, I found it good to ask two kinds of technical questions, one that the candidate chooses themselves basically, and one where the candidate does not know the answer or admits weakness in the area.

Trust me, you want to have someone on the team who can admit Oh, I do not know this., and goes off and figures it out. The candidate who can't admit not knowing something could be a liability during critical moments, and the team could be blindsided because they make stuff up rather than pointing out that they do not know the answer. You are the leader of the program and you own it. A failure of the team is the leader's fault and not the fault of an individual team member – always remember that. That's why hiring and retaining the right people is critical.

Besides having technical understanding, great communication skills to explain vulnerabilities and describe the business impact of issues can help tremendously to resolve issues quickly. Ideally, the communication style involves conveying interesting stories to get stakeholders engaged.

One area to probe during an interview is ethical questions. Bring up a scenario that requires a penetration tester to make an ethical decision. Let's say the pen tester is tasked with compromising an HR or internal employee feedback and rewards system. The objective is to gain access and demonstrate if data exfiltration is possible and if detection is in place. How would the candidate approach this? Would they exfiltrate their own record, exfiltrate the records of others, or propose to exfiltrate dummy records, or would they have any other ideas? See if the candidate acts according to the values you want to see in your program, team, and organization.

The best way to find good candidates is via referrals, in my opinion, so make sure that you are well connected with the industry. Attend conferences and ask around to see which candidates might be interested in your business.

Diversity and inclusion

The 2017 Global Information Security Workforce Study set out to report on the current state of women in cybersecurity. One of the key takeaways is that women make up 11% of the global information security workforce. If that sounds low, well, that's because it is. And 11% is the same percentage as it was in 2013, which means the situation has not changed over the last few years.

The details of the report can be found here: https://blog.isc2.org/isc2_blog/2017/03/results-women-in-cybersecurity.html.

The lack of diversity becomes apparent when walking through the halls of some security conferences. Since security conferences are critical for networking and recruiting, a welcoming atmosphere for women will go a long way.

To add to that, the Global Information Security Workforce Study highlights that, for non-managerial positions, the pay gap has widened from 4% to 6% and that women disproportionally fill lower-level positions, not senior, director, or executive roles.

What does this mean for penetration testing and red teaming?

To build a strong and successful offensive security program and to promote alternative analysis, having a diverse set of opinions, ideas, and viewpoints is a natural component of success. Your program is missing alternative viewpoints and adversarial tactics due to the lack of insights from female security experts.

Management must identify, support, and value women with high potential by providing opportunities for training, mentorship, and leadership. Additionally, it's desirable that your organization forms or participates in external online groups and in-person meetups focusing on women in security.

And if you are in a meeting and see there are a few women sitting off to the side, maybe it's because they feel like they don't have a voice. Anyone can invite and encourage them to sit at the table. The point is that all the small things make a difference.

Morale and team identity

It's all about the team. A big part of the success of a penetration testing team is morale and identity. Having a neat name for the team will help build that identity. And I don't mean calling it something like <Company here> Red Team or <Organization> Red Team. Pen testers are creative individuals, so come up with something fun that represents who you are and what you are setting out to do! Naturally, this develops by itself over the course of a few operations together.

At one point in my career, I formed a team and decided to give it a rather menacing name. It seemed a good idea and the name had naturally evolved via some previous tooling that had been built. So, I created a nice red logo with a yellow font. I spent many hours the night before building the slide deck to convey the idea of an internal offensive security team to my leadership. I basically went through the steps we are discussing in this book. From my point of view, it seemed like a pretty neat slide deck.

The actual presentation, though, went not as smoothly and did not progress beyond the first slide for a long time. Unfortunately, one member of the leadership team did not like the name of the team or its logo. I vividly remember how the director looked at the slide and then lowered his face and put his hand on his forehead. He felt that the name of the offensive team and its logo were too menacing and didn't want them to be used. The other directors were very supportive, however, and there was a leadership change soon after that, and things went the way I had planned.

From that point onward, all the work, operations, tools, and projects the offensive team worked on were given fun and sometimes cute names, such as bunny, squirrel, and things along those lines. It was especially entertaining and positive for the team's morale to see notifications and alerts highlighting the discovery of bunnies in the environment and things along those lines.

The pattern for picking code names prevailed, and the underlying background story of how we got there became a binding element for the team's identity. And there was no shortage for good names for tools and operations going forward.

One different aspect to consider when it comes to morale and team identity is the impact that purple teaming (close collaboration between red, blue, and engineering teams) can have if done incorrectly. It can threaten the team's identity and the morale of the red team significantly. We will discuss this more in Chapter 3, Measuring an Offensive Security Program, but it's important to maintain a healthy adversarial view and not only do purple teaming.

The reputation of the team

As a manager, considering the reputation of the team across the organization is critical. If it's correctly formed and led, the outcomes of an offensive security team are very visible across the organization. And it's up to the team to use this visibility and acquired power to inform the right stakeholders to drive the correct change and improvements across the organization.

An arrogant attitude does not help in the long run. It is in fact toxic. It's one of the earlier maturity stages of a red teamer. An immature red team, for instance, might become defensive when getting caught during an operation. For a manager, observing how the team handles "being caught" during an operation helps to gauge the maturity of team members and the program. By observing the interactions between the red team and the blue team when unexpected detections occur, a lot of learning can be done.

The more seasoned red teamer will embrace a detection and provide praise to the finder. Additionally, the seasoned red teamer will try to understand how it happened and try to achieve positive outcomes and improvements. With the knowledge of the product engineers or the blue team, even more effective attacks or variations could possibly be carried out that need mitigation. No one by themselves knows everything, and the viewpoints of others could lead to even more discoveries!

Showing signs of arrogance and ego is an attitude that's not uncommon among us red teamers. When dealing with strong egos, additional management and coaching will be needed to ensure the skill and power of the individual can be leveraged to their fullest potential by having the most impact.

The most successful pen testers I have encountered are humble yet assertive and provide alternative views to surprise and educate people without being arrogant or a know-it-all.