Ask Why

There are many things that go into good security engineering work. One of these is gaining a deep understanding of how things work. In other words, “asking why”, rather than taking an answer and accepting it.

Before you read this, watch this 7.5 minute clip of an interview with Richard Feynman.

My natural tendency, and I suspect this is true of many others working in security, is to want to delve deeply into understanding how things work. When I learn of a new interesting product or feature I want to take it apart. Some of the recent excitement in machine learning and AI has led me to both play with tensorflow and pytorch usage to understand how models are built, but also to investigate their internals to understand how they work under the hood. The Machine Learning Crash Course, Andrej Karpathy’s Neural Networks: Zero to Hero videos/notebooks, and Jose Duart’s blog post on updates to the Tensorflow threat model are a few good starting points, if you’re so inclined.

In the context of the Feynman interview, I don’t want to stop at understanding why magnets repel or attract. I want to delve into the physics student understanding of ferromagnetism, which leads to asking why that works the way it does. This leads to wanting to understand more about atomic structure and quantum electrodynamics. It is a never ending series of asking “why?”, eventually ending in giving up due to a lack of time or running into unsolved problems in physics and not wanting to spend time solving those.

Security reviews are very similar to this. Presented with a product or feature, I want to know how it works and why I should trust it. Asking the question “why does thing A behave in a certain way” leads to asking how it works, which often leads to why things B, C, etc. all operate the way they do. Eventually we either satisfy our curiosity and run out of questions, or we give up because we run out of time.

In a bit more detail, if I’m reviewing a product written in Rust there’s an enormous amount of context necessary to determine how deep I go. If it’s a web server that can easily be updated, I am not going to focus on how resilient the code is to glitching attacks that require a person to have the tools necessary to carry out a sophisticated clock or voltage glitching attack. If on the other hand the Rust will be used as a mask ROM that must be hardened against these attacks, I will try to make sure that the code takes this into account.

I think that once again, my point is that context matters. Sometimes the context will be something implicit that is well understood by everyone involved. Other times, it leads to asking why.