Bookworm Friday: Five Books Recommendations by Szymon Wyrwiak
In this series, we ask our William Hill colleagues to share their favourite book recommendations and tell us what specifically they learned from them. Today we present five recommendations from Szymon Wyrwiak.
On a daily basis, I try to keep our AppSec board afloat, shield my team, let them work on things that matter, define our backlog and have a blast working in the security area.
I like when a book tells the story about the person that reads it. I want to be deliberative about my actions and explain why these books were part of my journey. Time of reading sets the order.
Gary McGraw, Software Security: Building Security In
It was the first book that I read about security. I was lucky enough to get my first job in the security field, and I did have to create an SDLC concept for one of our clients. I was very excited about my work; the company startup culture and many people surrounding me were also enthusiastic about security. Many recognizable people like Dawid Czagan, Michał Bentkowski, Adrian “Vizzdoom” Michalczyk and Marcin Piosek were working in FP. I was a lone wolf, so they may not remember me, but anyway, big thanks for this chance.
I'm also thankful to Gary McGraw for letting me use part of the book in my presentations.
Michal Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications
After having a high-level view of how security fits into the product development model, I wanted to know what led us to the current security state on the web. I have to be honest - this book was not an easy read. It's a bit tangled on its own, but it gives crucial insights into the underlying mechanics of web applications and why they're fundamentally insecure. It's valuable information that builds the basis for other skills. I ended up reading it a few times.
Dafydd Stuttard, Marcus Pinto, The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws
This book reminds me of a crazy time when Andreas Hauke created a new security team in SAP hybris. For a few months, we did have a team of only two people to cover quite an extensive product portfolio. There was a lot of work and a lot of learning. I'm still impressed with the SAP investment in their area and their approach to threat modelling. As for the book, it was probably part of our team identity. I remember one owned by Andreas. It was pretty used. I ended up holding a few books from the series; it's a must-have with a lot of information.
It's not as much about the book as about doing the assessment, especially the full one (CliftonStrengths 34). I always wanted to help other people develop themself. When I was not mature enough, I did it so that they did feel after my coaching worse than before. I was assuming that people see the world in a way similar to mine. Once I was a father of two boys, it hit's me that I was simplifying many things, and this simplification may hurt others.
I started to listen to the Gallup podcast, undergo assessment, convince my wife and a few friends to do it, and I'm still paying for the top 5 assessments for every team member who joins our team, even for a brief moment. It helps us to understand ourselves and communicate better.
It changed my approach to people. Now I see that everyone is different, and I have to tailor my approach, backlog and communication model to make everyone happy.
Laura Bell, Michael Brunton-Spall, Rich Smith, Jim Bird, Agile Application Security: Enabling Security in a Continuous Delivery Pipeline
Once I started to work more as a product owner of my team. I made a few mistakes at the beginning. I was too ambitious and wanted to deliver security services that were not viable in our environment. Even though I had a one-person army on my side (a.k.a Ederson Brilhante), it was not enough to succeed.
I realised my mistakes and changed our approach, now we focus on static pieces, analysers and avoid any components that will need our ongoing live support. We think about long term scalability and support models. That change wasn't probably happening quickly without ongoing discussions with people like Robert Knowles, Rafael Pandini and Daniel Jezierski. This book worked a bit as a blueprint for our work model.