, ,

New Whiteaboard Hacking training: advanced and for pentesters

One of Toreon’s key values is the gathering and sharing of knowledge. We try to encourage our own people to do this all the time and actively facilitate this. Knowledge grows exponentially when shared and combined with people of all knowledge levels, even if they come from different IT security domains.

This made us realise that we have a lot of knowledge to share. We see it as our duty to help train top notch IT security specialists. First we started to train the Toreon employees and later on also clients’ employees, which we have been doing for several years now. All this knowledge is now also available for your organisation. The better your people are trained and prepared, the more we can all focus on our main objective: creating a safer digital society.

We have expanded our knowledge base and have finetuned our workshops and trainings and are now also offering them to be booked for conferences and in-house company training.

Our Whiteboard Hacking training has been doing so well (OWASP AppSec Europe 2017 in Belfast, Northern Ireland – Black Hat USA 2017 in Las Vegas, USA – O’Reilly conference 2017, NY, USA) that we’ve developed an advanced version, which is already scheduled for Black Hat 2018 (USA and Europe) and BruCON 2018 (Ghent, Belgium):
BlackHat Las Vegas, USA (August 2018)
BlackHat London, UK ( December 2018)

We recently started with versions for pentesters and DevOps engineers: Offensive whiteboard hacking for penetration testers. Already available at:
– BruCON 2018, Ghent, Belgium (October 2018)
– DevSecCon 2018 London (October 2018)

Check out all the details of our available AppSec trainings.

Contact us for an in-house training offer, tailor made to suit your needs.

, ,

Our ‘Adding Privacy by Design in Secure Application Development’ talk at OWASP London

On 5-June Seba delivered the talk “Adding Privacy by Design in Secure Application Development” at the OWASP Europe conference in London.

Seba addressed the complex GDPR challenge for developers as part of a Secure Development Lifecycle approach.

The presentation covered:

• GDPR requirements covering design, data lifecycle, users and end of life aspects
• Privacy by Design challenge
• Including GDPR in the Secure Development Life Cycle
• Mapping OWASP SAMM to the GDPR
• Integrating privacy in application security classification, awareness training, guidelines, AppSec champions, threat modeling, 3rd parties, security testing and incident management
• Introducing GDPR risk patterns

Our talk focussed on practical implementation aspects and demonstrations of real life use cases encountered in our software security and privacy projects.

You can download the slides here.

, ,

OWASP threat modeling podcast

Our Steven Wierckx (@iHackforfun) joined the application security podcast to talk about the OWASP Threat Model Project in which he has taken the lead.
Click here for the podcast…

Enjoy!

,

Gain more insight and create doomsday scenarios for better threat modeling

In previous blogs you could already read about what threat modeling is, and about the 4 steps. In practice, however, threat modeling is more than just a technical analysis of your application. The threat landscape is constantly evolving, and so is your organisation. Therefore, you need to understand the technical and business context, and create doomsday scenarios. As a result, you have a broader insight of the threats to your application.

  1. The ecosystem

Applications are not always stand-alone. On the contrary: they are mostly part of an ecosystem of applications. You need to find out how it works and how it supports your organisation. You also need to have a clear understanding of the security requirements. You should, for example, know what other applications or services the application is exchanging information with.

  1. The business context

What business process is being performed or supported? What are the characteristics of that specific process? And how crucial is that process for your business? You also need to find out who is using the application and identify possible threat actors. In most cases, they fall into one of the following categories:

  • Insider trusted: privileged users
  • Insider untrusted: very regular users, contractors …
  • External trusted: suppliers, partners, service providers …
  • External untrusted: competitors, cybercriminals …

Eventually, you need to identify risks for your business: what is the impact and what is the probability that a certain risk will occur?

  1. The added value of threat modeling

Threat modeling is quite time-consuming and thus expensive. It is therefore only relevant for important applications: those that bring in a lot of revenue or handle important data for your organization.

  1. Create doomsday scenarios

 Doomsday scenarios are hypothetical situations: the worst that could happen for an application – and for your business. Creating doomsday scenarios helps you to proactively anticipate – and even prevent – possibly catastrophic events. You need to describe the following:

  • Threat sources: who would be interested in compromising the applications? Why would this be interesting for an attacker?
  • Impact: what will be the impact of an attack? Some of the possibilities are theft, loss, corruption and disruption.
  • How: how will the scenario be realized? Describe in detail how the attack would be performed.

These scenarios give feedback on your current security situation. You will discover more potential risks and steps to be taken to reduce these risks.

Could you use some more explanation? Click here to download our free ebook.

,

Want to take your application security to the next level?

When you build an application, are you sure it is safe? Are you certain attackers won’t be able to gain access to private or potentially injurious data? And are you absolutely convinced that an attacker is not able to crash the availability on your system?

Read more

Threat modeling in 4 steps

We convinced you of the use of threat modeling in a previous post. But where and how do you start? Threat modeling is performed through a series of workshops. Architects, developers and system administrators are guided through the threat modeling process. It is the primary security analysis task executed during the software design stage. Threat modeling is typically performed in 4 steps:

  • Diagram: what are we building?
  • Identify threats: what can go wrong?
  • Mitigate: what are we doing to defend against threats?
  • Validate: validation of previous steps and act upon them

Step 1: diagram the application

In this step, you gain a comprehensive understanding of the mechanics of your application. In other words: you understand what you are building. That makes it a lot easier for you to uncover more relevant and more detailed threats. This also includes the identification of clear security objectives. They help you to focus the threat modeling activity and determine how much effort to spend in the following steps. When you have documented the important characteristics of your application and actors, you can identify relevant threats during the next step more easily.

Step 2: identify threats with STRIDE 

You use details from the previous step in the STRIDE phase to identify threats relevant to your application scenario and context. With STRIDE, you can flawlessly identify what can go wrong.

STRIDE was developed by Microsoft to educate developers on how to think about computer security threats, and is an acronym for:

  • Spoofing: can an attacker gain access using a false identity?
  • Tampering: can an attacker modify data as it flows through the application?
  • Repudiation: if an attacker denies doing something, can we prove he did it?
  • Information disclosure: can an attacker gain access to private or potentially injurious data?
  • Denial of service: can an attacker crash or reduce the availability on the system?
  • Elevation of privilege: can an attacker assume the identity of a privileged user?

Each of these threats is the opposite of a property that you want your system to have. Spoofing – for example – is the opposite of authentication.

Step 3: mitigate identified vulnerabilities

In this step, you review the layers of your application to identify the necessary security controls related to your threats. Vulnerability categories help you focus on those areas where mistakes are most often made.

Step 4: validate

The final step is to validate the whole threat model. Is each threat mitigated or not? And for unmitigated threats: are the residual risks clearly explained and tied into business risks? In the validation step, you also decide and follow-up on the next steps to manage the identified threats.

Do you want to take your application security controls to the next level? Say no to threats and book a seat in our open Hands-on Threat modeling training.

Threat modeling: what is it, how does it work and why is it so important?

You might have heard of threat modeling as a structured activity for identifying and managing application threats. And that’s exactly what it is. Threat modeling – also called Architectural Risk Analysis – is an essential step in the development of your application. Without it, your protection is a shot in the dark.

Multiple security issues, a timely approach

When you create a piece of software, you will face multiple security issues in different phases of the lifecycle, such as security design flaws, security coding bugs and security configuration errors.

Reducing risks effectively equals starting with threat modeling as soon as possible. That is why it is typically done during the design stage of a new application. Threat modeling allows you to find vulnerabilities and to consider, document and discuss the security implications of design, code and configurations.

4 essential steps

Threat modeling is typically performed in 4 steps:

  • Diagram: what are we building?
  • Identify threats: what can go wrong?
  • Mitigate: what are we doing to defend against threats?
  • Validate: validation of the previous steps and act upon them.

Want to gain more in-depth insights about these steps? Read our blog post Threat modeling in 4 steps.

Why you should start with threat modeling

One of the major advantages of threat modeling is that you prevent security flaws when there is time to fix them: in the design phase. But there are many more reasons to start with threat modeling today, such as:

  • You select a mitigation strategy and techniques based on identified, documented and rated threats.
  • You identify and address the greatest risks.
  • You are able to prioritise development efforts within a project team based on risk weighting.
  • You increase risk awareness and understanding.
  • You use mechanisms for reaching consensus and better trade-off decisions.
  • You also make use of threat modeling to communicate results.
  • You benefit from cost justification and support for needed controls.
  • You use artefacts to document due diligence for each software project.

Do you want to discover everything you need to know about threat modeling? And get concrete tools to implement threat modeling in your organisation? Book your seat in our Hands-on Threat modeling course.