, ,

OWASP BeNeLux Days 2018

I love working with OWASP because I strongly believe in the values of knowledge sharing and community building. I personally started the OWASP Belgium chapter in Belgium in 2005. Today, I am also very active as co-leader on the OWASP SAMM project.

When I started my company Toreon (cyber security consulting), I tried to instil the same values to the business. I attracted people with the same mind set of knowledge sharing. Now many of my colleagues are active at OWASP and Toreon’s Steven Wierckx is the project leader on the OWASP Threat Modeling Project.

We believe that donating time and money to open source projects and the OWASP community can really improve the overall security of software (realising Toreon’s mission of ‘Creating trust for a safer digital society’).

At the same time we learn a lot by being active in these projects and we build a network of specialists and friends within the OWASP community.
We also put our money where our mouth is: Toreon is a proud sponsor of the OWASP Belgium chapter and the upcoming OWASP BeNeLux Days on the 29th and 30th of November in Mechelen, Belgium, which has great free trainings and line-up: check it out here.
Make sure to come to the conference and if you can, become a (personal or corporate) OWASP member! And please tell all your friends and colleagues about OWASP.

At the conference, come and say hi at our booth! You can win a book from Adam Shostack on Threat Modeling or a Google AI do-it-yourself kit with an intelligent camera and Raspberry PI.

, ,

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

Security of Normalized Systems

I had an interesting conversation with Prof. Dr. Jan Verelst of the University of Antwerp. They (Prof. Dr. Jan Verelst together with Prof. Dr. Herwig Mannaert) created the theory of normalized systems.

A normalized system is created following a set of rules, which ends up making the software as ‘atomic’ or ‘modular’ as possible. Software modules are split up to the smallest units possible. This creates software that has no ‘ripple effects’, meaning that updating a part of it, adding functions and features, or changing underlying systems needs minimal effort. Software stays nimble and changeable.

After working many years on the theory, they started NSX to bring this concept to market. They have now had several successful projects. I am interested to see if the promise of making systems nimble and easy to change comes true.

Our conversation was about how normalized systems relate to security. In effect, a NS is not secure by default, but there are quite a few benefits when it comes to security:

  • if a flaw is found in the code expander (the ‘blueprint’ of a piece of code), fixing the expander allows for all software based on it to be easily updated to the newer, safer version
  • if there is a problem with the underlying system (OS or hardware), the code can be generated quickly for a different system
  • if a developer introduced a problem in the (limited) human generated code, it is easily tracked and replaced without effects on other modules, since the modularity is so extreme

All in all, I expect great thing from NS. Making code modular doesn’t automatically make it more secure, but it limits the damage and makes it easier to fix.

,

Embedding GDPR in the secure development lifecycle (SDLC)

Did you know that the GDPR and SDLC re-inforce each other and that the GDPR can be used as the ideal business case to start with SDLC? Siebe and I explained how and why during the OWASP AppSec Europe conference in Belfast. Couldn’t attend? You can find the presentation in our previous blog, or begin by reading the introduction below.

We all know that in less than a year the GDPR (General Data Protection Regulation) enters into force to unify the privacy legislation within Europe and the UK and improve the protection of personal data and data subject rights. And I don’t need to tell you that the secure development lifecycle (SDLC) method is thé go to methodology when planning for, designing, building, testing and delivering information systems. But if you play it smart, you can improve your SDLC by including GDPR activities and use SDLC artifacts to demonstrate compliance with GDPR.

A lot of articles in the GDPR specifically refer to security. Article 25 for instance, on privacy by design & default, article 32 on Security of Processing and article 35 on DPIA’s all specifically mention the security levels and assessments that should be considered. The most efficient way to comply with these GDPR security requirements when developing (new) applications, is by integrating them into your Secure Development Lifecycle.

You can find more information on the OWASP Software Assurance Maturity Model (SAMM) and how it can be integrated into any existing SDLC here. For now, it suffices if you know that OpenSAMM is defined in different levels.

  • At the highest level it is divided into four tasks or concerns to consider while developing or using software. They align well with a typical organisational structure, and this is how software security typically ties into an organisation.
  • At a lower level, several security practices are defined that should be considered for improving software security.
  • At the lowest level, every security practice consists of a set of activities, ordered in maturity levels or objectives.

The GDPR articles related to security fall perfectly into these activities. Just check out this table:

SAMM domains

 

So, when you divide for example the GDPR requirements on Policy & Compliance into three objective levels, this is the result:

PolicyCompliance

More examples and details can be found in the presentation in our previous blog. Or get in touch!

 

,

Presentation “Embedding GDPR in the SDLC” available for download

Last week Thursday we delivered our presentation “Embedding GDPR in the SDLC” at the OWASP AppSec Europe conference in Belfast.
The presentation is the outcome of various projects where we encounter both privacy and application security challenges.
Siebe De Roovere (one of our privacy specialists) and myself have worked on integrating GDPR compliance requirements in a secure development life cycle.

SAMM – GDPR mapping

For secure development life cycle projects we use the OWASP Software Assurance Maturity Model (SAMM). This is an excellent maturity model with concrete guidance on application security activities. You can integrate these activities in your software governance, development, testing and operations. We identified the GDPR requirements and deliverables and mapped these on the SAMM activities.
This way we improve both software security activities and can demonstrate GDPR compliance with the security deliverables. One example is a documented threat model , that includes the outcome of a data privacy impact assessment.

Download

There was a lot of interest for our session and we had great questions and feedback at the end of our presentation.
The slides of the presentation are available for download here: TOREON_Embedding_GDPR_into_the_SDLC_OWASP_AppSecEU_Sebastien_Siebe_V20170511
We will let you know when the video of the presentation is available.

We decided to donate the SAMM/GDPR mappings to the OWASP SAMM project and will organize a working session during the upcoming OWASP Summit in June to develop this further.

In the mean time: we do encourage you to provide us feedback and/or input to improve the current mappings!

Kind regards,

Seba & Siebe

,

Seven advantages of penetration testing

In a previous blogpost we explained what penetration testing is and how it can help improve your security. Time to take a closer look at the 7 benefits pentests have for your company.

  1. Reveal vulnerabilities

Penetration testing explores existing weaknesses in your system or application configurations and network infrastructure. Even actions and habits of your staff that could lead to data breaches and malicious infiltration are being researched during penetration tests. A report informs you on your security vulnerabilities so you know what software and hardware improvements you have to consider or what recommendations and policies would improve the overall security.

  1. Show real risks

Penetration testers try to exploit identified vulnerabilities. That means you see what an attacker could do in the ‘real world’. They might access sensitive data and execute operating system commands. But they might also tell you that a vulnerability that is theoretically high risk isn’t that risky at all because of the difficulty of exploitation. Only a specialist can perform that type of analysis.

  1. Test your cyber-defence capability

You should be able to detect attacks and respond adequately and on time. Once you detect an intrusion, you should start investigations, discover the intruders and block them. Whether they are malicious, or experts testing the effectiveness of your protection strategy. The feedback from the test will tell you if – but more likely what – actions can be taken to improve your defence.

  1. Ensure business continuity

To make sure your business operations are up-and-running all the time, you need network availability, 24/7 communications and access to resources. Each disruption will have a negative impact on your business. Penetration tests reveal potential threats and help to ensure that your operations don’t suffer from unexpected downtime or a loss of accessibility. In this respect, a penetration test is quite like a business continuity audit.

  1. Have a third party expert opinion

When an issue is identified by someone within your organisation, your management may not be inclined to react or act. A report from a third-party expert often has a bigger impact on your management, and it may lead to allocation of additional funds.

  1. Follow regulations and certifications

Your industry and legal compliance requirements may dictate a certain level of penetration testing. Think about the ISO 27001 standard or PCI regulations, which requires all managers and system owners to conduct regular penetration tests and security reviews, with skilled testers. That is because penetration testing focuses on real-life consequences.

  1. Maintain trust

A cyber assault or data breach negatively affects the confidence and loyalty of your customers, suppliers and partners. However, if your company is known for its strict and systematic security reviews and penetration tests, you will reassure all your stakeholders.

Interested to learn how we can help? Just let us know!