Products, Not Process
Returning home from a great Suits and Spooks in D.C. last week, the words of one presenter stood out: products, not process are what really matter in security engineering.
Ali-Reza Anghaie (@packetknife) was presenting on “Security Economics – Competing in a Obese and Insecure Intellectual Property Landscape“, and ended his speech with several key takeaways, products over process being one of them. In practice, he explained this philosophy as a key part of his security training where he makes security engineers shadow other people in their organization. Through following their colleagues in day to day work, security teams can better understand what exactly they contribute to securing, and hopefully empathize with some of the trade offs their peers make in accepting security over the features that marketing/sales/developers want to implement.
What hits home most, for me, was that the balance between security, freedom, and convenience has to truly be seen as a balance. Through engaging with the “product” side of the organizations we aim to protect, sometimes it’s more helpful in the long run to sacrifice some security.
In broader practice, Ali-Reza’s talk kept returning me to the same set of questions, where the adversarial approach of “How can we disrupt what companies value?” I usually depend on for security audits can be flipped into collaborative questions of “How can security practices benefit our core product, IP, or service?”
Security is at its worst when practiced separately from the rest of the organization. In this misguided line of thinking, the trap that teams tend to fall into seems to be ‘process’. In my security assessments, I’ve seen this happen at worst when teams equate compliance processes as security, or even at best they have the resources to run red-team ops and buy a plethora of appliances without clear objectives. Getting caught in the appeal of ‘process’ detracts from the long-term success that comes from contributing to the real output of an organization, even it comes with difficult compromises where security is less important than other concerns.
At the end of the day, we can’t engineer security in the void of “process” whether its HIPAA compliance or our own risk management frameworks. Engaging other teams, systems, and products in the organization will only be increasingly vital as information security continues to climb in importance to the board room level.