Investments Unlimited
A few weeks ago, I was headed to Amsterdam for our user conference (Alteryx Inspire EMEA). Anytime I travel, I usually get deep into an audiobook. I was able to finish one before take-off, and attempted to reflect a bit on the plane – but life gets busy, and I am just now getting around to talking about it.
I was recommended a book (Investments Unlimited: A Novel About DevOps, Security, Audit Compliance, and Thriving in the Digital Age) by a colleague (Cory Stoker) last month, that on the surface appeared to be like The Phoenix Project (Gene Kim), but for security and audit compliance. I know The Unicorn Project (Gene Kim) touched on security a bit – but this book resonated with me a bit more as several of the topics are items I have recently had to think about or dig into at some level this year. At a high level, it’s a story about a financial institution that was put on notice about releasing products that were full of defects, and showed a lack of rigor around security – and they had to fix this in order to regain faith with the auditors. From within the business, consensus is generally that everything appears to be working, it’s assumed that folks are following process, things are tracked, developers are following the practices they should, etc. After digging a bit deeper several different issues begin to surface. Asset inventory/CMDB not up to date, Change Advisory Boards (CABs) are seen as useless and slow even by those on the board, developers have numerous different build systems, teams using different pipeline processes and policies, and the list goes on.
At my current gig at Alteryx, we are working on getting many of our products under ISO27001 and SOC 2 Type II, if they are not already. In approaching this work, working with my Product Management and Engineering colleagues, I am one of the few people at Alteryx that has to find a way to reach numerous development teams, understanding what they are working on, what code reaches production or is released to customers, what processes they follow, and determine where any deficiencies are so that we can work together to fix them. In doing this work (and coming from the engineering and product side of the house previously), I am very aware that heavy process, gates, and sometimes even taking away development time to chat about the security topic of the week are not always viewed favorably by those teams. They are often focused on meeting deadlines and trying to determine how to go faster while leaving the least amount of technical debt in their wake.
While this book had no silver bullets, the message was clear; automate everything you can, security should not be a blocker to going fast, and things are not always what they seem at the surface. I would recommend this book, especially to my fellow Product/Application security and DevSecOps peers.
