Offensive Security Workshop: Why And How? Part 1.

Motivation

We are living the days where a battle is being fought for our personal data. No single month can pass without reading about a new data breach. The small players were not the only ones being effected. Big companies were also victims of cybercrime recently, just think about Uber, Deloitte or Equifax

In order to successfully create and operate a software, an application security team is a good start, but it is not enough. We can try to ensure security best practices and we can try to limit the potential attack surface, but to have a good night sleep we need more. At Emarsys we believe that security should be every developer’s concern. To emphasise this philosophy we regularly organise internal security trainings and workshops. In these events we raise awareness to the dangers our application is facing.

This blog post is about how we redesigned our typical security awareness training to make it interesting, instructive and challenging for developers. To find out more about this process, the challenges we faced and the solutions we came up with just keep on reading!

Is this post for me?

If you are a security engineer you are on the perfect page. Although your exact situation is probably different from ours, you will see the problems we faced and the decisions we made.

If you are a developer, do not stop reading, either! Secure coding is a valuable competence and if you wish to sharpen your skills this is definitely a good place to start. If you like our methodology forward your security team this page and ask them to create a similar event.

From presentation to participation

We used to organise security trainings before, but they followed a more traditional format and there was clearly room for improvements. It was usually held for larger groups once or twice a year in a traditional presentation format. We wanted to see how we can make it more effective. Therefore we decided to put a little twist into our regular order. Instead of going through principles and best practices of secure coding we decided to turn the tables and give the participants a chance to “hack” their way through the training.

We think the offensive workshop format is better because hands-on training can give participants a chance to see how a potential attacker thinks when he or she inspects a system. The question is not “how secure is this application” but “can I find a weak spot”? If you look at your software with this question in mind, you are more likely to spot dangerous design decisions or wrong implementations. Acting like a hacker for a short time also has a coolness factor for some developers, it is easier to get their attention with this scenario and they are more likely to remember the training later.

What you should consider

Time constraints

Time is money and we can’t borrow our developers from their teams for weeks only for a single security training. We were looking for the best return on investment, where everyone can get the key messages and profit the most without dropping out from the everyday schedule for too long. We decided to go with a 3 hour long workshop with one short break. This is an intense morning with two 90 minutes long sessions ending before lunch time. In the afternoon everyone can go back to their team and continue with their regular jobs.

Group size

An offensive workshop can only work well in small groups, where every participant gets the right amount of attention and no one gets lost halfway through the training. We decided to go with maximum 20 people. If this number is too small, not enough people can get the training and we waste resources. If it is too large, some participants might not get enough attention and they won’t understand what we are doing.

Target audience

Next question was the list of participants. Should we create an open application form? Or should we select a target group? On one hand we could invite the new joiners because they are still onboarding and they should learn about secure coding as soon as possible. On the other hand we could invite the senior developers with the most experience because they are usually involved in every important decision and they should always consider the security aspects of a question. Finally we decided to go in a different direction. Our goal was to spread the knowledge as much as possible. We created an application form and gave a one-week sign-up period for everyone who was interested. Then, when we closed the registration we had a list of colleagues who are enthusiastic to learn more about security. In the end we selected 15 of them the only criteria being to include only one member from each developer team. This way most teams will have a member who participated in the workshop and is enthusiastic about security. These individuals are more likely to learn from the workshop and apply this knowledge in the team’s coding practices. Later they can even be members of other security awareness programs as well.

Challenges to solve

The greatest problem we faced in the organisation process was the selection of the right challenges. Going deep into one specific area was not a good idea in our case. We wanted the workshop to be a standalone event that covers as many topics as possible. The participants don’t need to know every detail about vulnerabilities, we just want them to be able to identify potentially dangerous situations where involving the security team is important. Going into specifics is only advised when you have more time to cover multiple topics in depth. This typically occurs when developers can take part in multiple events.

Select a platform

An interactive workshop needs a software platform which offers prepared websites as targets, where the security holes can safely be exploited. A lot of ready-to-use solutions exists, they are usually used for hacker challenges beside educational purposes. We were also thinking about developing our own version but the project got postponed. After taking a closer look into the existing sites we decided to use Avatao. It is a great platform for security trainings because it provides easy-to-use hands-on challenges and sandboxed environments for solving them. These challenges can vary from finding bugs or security holes through fixing them to secure coding exercises. We decided to use their solution because lot of the challenges are offensive web security tasks, just what we needed for the kind of training we had in mind.

Do prepare in advance

Providing participants a great experience during the workshop is really important if we want them to enjoy the event and remember what they learnt. So, before the workshop could begin we had to prepare some things in advance. A dedicated list of challenges was assembled in the Avatao platform with the exact exercises we wanted to have. We solved every challenge in advance multiple times and even created a one-page cheat sheet with all the solutions. We also measured the necessary time for each exercise and created a detailed timeline so we could always know if we are proceeding too fast or too slow.

How did we select the challenges?

Most of the selected challenges fall into these categories:

• Injection type attacks: these are the most common threats of the web. The attacker needs to inject untrusted data into a system and he or she has to convince the system to process it.
• Authorization bypass: it can happen if an application’s access control is not implemented consistently or the framework’s build-in authentication features are misused.
• API exploitation: Our core application has a large API so the third topic we decided to include was API related vulnerabilities and anti-patterns.

In order to define these challenges we first went through vulnerability topics to pick the ones that are relevant to our products. Next we took a look at our previous security related bug tickets and decided on a list of topics that covered a wide attack surface but didn’t go into details too much. The OWASP Top 10 list collects the most critical web application security risks, it is a good starting place for anyone wishes to select topics for their similar workshop.

Beside hacking challenges what should we include in the workshop? Taking small breaks between the exercises and showing real life examples should be part of the agenda. It could make the workshop even more relatable and connects the exercises with challenges developers will probably face in their everyday life.

Going live

After weeks of brainstorming, challenge solving and organising the workshop was ready to be launched. We came up with a new security workshop format, selected the right participants and prepared the best challenges for them. If you want to know how the execution went, how the participants felt about the new format and what conclusions it led us to, make sure to read the second part of this blog post! See you in a few weeks.