Don't panic.... I've got a towel

About two weeks ago, I gave a talk on our Code & Comedy event. I showed a security gate that's also a ladder, funny machine learning data sets, password jokes and many more funny memes about security. I did what I like most: make people laugh and teach them about security without them realising.

Some days after that, it was back to being serious, but still doing what I like most: give context and meaning to non-technical people about highly technical findings. This wasn't the funny, lighthearted humour that was Code & Comedy, but I was exactly where I wanted to be. I could help take away panic and replace it with logic. Panic about things breaking that you thought were unbreakable is natural. But it's much better to stay cool, assess the findings and fix the issues. That's why we search for things that could break, find out how they can break and fix the flaws before the bad guys do it.

This practice actually has a name: threat modelling. It's a thing you do, before you even start implementing stuff, during the design phase. In the OWASP SAMM model, this practice falls under Threat Assessment. Most organisations just add a pentest, just before "going live" and then panic when pentesters show up with a lengthy report. And yes, it's much more effort to fix things in the end than discovering and fixing early on. But still, you want to let your pentesters break stuff and find the flaws before the bad guys do. Appreciating and accepting these findings instead of panicking is a bit harder. I'll quote a pentester: "You have to tell customers horrible news in a way that makes them not want to immediately stab you in the throat." - Dan Tentler on Hak5.

Lets' talk TDD. Most clients have a pretty good idea of what functionality they want to see in their solution. We build tests to verify that behaviour. In test-driven development we increase the desired functionality by writing tests for future functionality. This is shown in yellow in the graph.

The pitfall here is validating only intended features: the happy paths. Although edge-cases are included occasionally in tests as well (as they should), unintended behaviour is often ignored. And that's where pentesters put their focus: finding these "hidden features" and trying to abuse them before the bad guys do it. We can then fix those flaws, "removing" the "hidden features". This is shown in blue.

Accepting and embracing this practice of trying to break our stuff is one of the most important first steps in secure software development. There's no such thing as bug-less coding. So expect bugs, flaws and security findings. Requesting a pentest and hoping for no bugs found is hoping for a bad pentest team. No findings is highly suspicious if you ask me. Knowing where your application fails is essential to make it robust, stable and secure. It's easy to scare people with FUD: Fear Uncertainty and Doubt. But it's much better to help people with FUN. Lessons learned with FUN stick around longer and create much better incentive to do the right thing: embrace failing as positive, learn from it and improve your systems.

A bit to my surprise, my employer sent me a token of appreciation for these efforts. I might be downplaying, but knowing the people involved and notified, the issue at first seemed like something serious. As I dove in I felt right at home in the dark, shining light on the technical, scary stuff. Within a few minutes I contextualised the findings, figured out how to delegate the issues and what to pick up first. This allowed me to give the best possible advise and convert panic to clarity. This removed the uncertainty and created transparency on the actual risks so decision makers could take informed action. I'll take words of appreciation any day, and seeing those in name of ppl high up in the organisation is quite a feeling (as far as our company even is hierarchical, our C-level management is incredibly approachable). What's even more important to me, is being able to do what I love most in my work.

So if you are interested in either a serious talk about securing the software development process, OWASP SAMM, cryptography, security testing, security awareness etc. or a lighthearted talk with lots of fun that secretly has some important security awareness lessons, feel free to contact me or my employer. If you are interested in a two day crash course for developers on SSDLC, feel free to contact me or my employer. If you are interested in a broadly oriented Java developer with a wealth of security knowledge to help you set up SSDLC, secure CI/CD pipelines, teach security awareness and overcome the gap between security compliance and development teams by translating compliancy standards to actionable.... actions: contact me or my employer ASAP. But do realise that security is not a black-box you can shove in. Security is not something you can just hire someone to do, so you don't have to think about it yourself. Security is a journey, a culture you have to cultivate, a way of working that never ends. It's an infinite game that never stops. But it's an incredibly satisfying game to play into an advantage. A game that gets you ahead of the game.