Posts

, ,

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.

, ,

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.

,

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!