The first part of the course introduces you to why secure programming is important and the business case for it. It also describes what is needed to be successful in secure development. After that the Secure Software Development Life Cycle (SSDLC) is introduced. It concludes with an overview of properties that make software secure or open it up to attacks if not implemented properly.

The case for software security
There is no place to hide security issues. They will be found and exploited if you don’t fix them in time. By postponing this work and creating technical/security debt you will only make it harder on yourself and increase the costs of something you will have to do eventually anyway. And if you don’t, you will be held accountable. Laws are getting tougher and society is raising its expectations of what it thinks is your responsibility. In the end it makes sense business-wise to improve your security stance. Especially when you take into account that the cost of security breaches always is higher than anticipated and is ever increasing.

Setting the stage for success
There is no simple recipe for making software secure. You need to build an environment that supports secure development. This means creating a culture where security is important and where this importance is reflected in communications and in the decisions that are made. It also means building and maintaining the right knowledge base and skill set to become and stay good at it. Once that is in place you need to adopt some best practices to ensure you get good results. Think of reducing complexity, practising defence in-depth, making maintenance easy, preparing for changes, and evaluating third-party code before incorporating it in your work, a.o..

Secure development models
Realise what it takes to “do” secure development by understanding and implementing the Secure Software Development Life Cycle. Even if you have adopted DevOps, this is still the basis for achieving success.

What makes software (in)secure?
There are many many ways in which software can be either secure or open to attacks. Using SECO’s Application Security Framework, a coherent overview of all these aspects of secure software is given. Because almost all software that processes data will have some link to databases, a short overview of database security is included in this section.

The second part of the course describes what threat modelling is, what it aims to achieve, and how it is done. This part will be concluded with a workshop wherein a threat model is made of a new service that our model organisation Bicsma wants to introduce to the market.

All four steps of the threat modelling process will be shown and explained:

• Modelling the system
• Modelling the threats to the system
• Mitigating the threats that were found
• Verifying the threat model

The third and last part of the course is purely hands-on. A number of the most common security issues are reviewed using practical examples. Think of:

• Input validation
• Buffer overruns
• Exception handling
• Command injection
• Integer overflows
• Information disclosure
• Race conditions

Exam

• Language: English
• Delivered: Online via a certified proctor
• Questions: 40 multiple choice
• Time: 60 minutes