Never Stop Coding

PostsThe Archives

Several members of Adobe’s security team have taken to the media to offer career advice to aspiring security professionals (you can read more about that here, here, and here). For those interested in security researcher positions, my advice is to never stop coding. This is true whether you are working in an entry-level position or are already a senior researcher.

Within the security industry, it has often been said, “It is easier to teach a developer about security than it is to teach a security researcher about development.” This thought can be applied to hiring decisions. Those trained solely in security can be less effective in a development organization for several reasons.

Often, pure security researchers have seen only the fail in the industry. This leads them to assume vulnerable code is always the product of apathetic or unskilled developers. Since they have never attempted large-scale development, they don’t have a robust understanding of the complex challenges in secure code development. A researcher can’t be effective in a development organization if he or she doesn’t have an appreciation of the challenges the person on the other side of the table faces.

The second reason is that people with development backgrounds can give better advice. For instance, when NoSQL databases became popular, people quickly mapped the concept of SQL injection to NoSQL injection. At a high level, they are both databases of information and both accept queries for their information. So both can have injections. Therefore, people were quick to predict that NoSQL injection would quickly become as common as SQL injection. At a high level, that is accurate.

SQL injection is popular because it is a “structured query language,” which means all SQL databases follow the same basic structured format. If you dig into NoSQL databases, you quickly realize that their query formats can vary widely from SQL-esque queries (Cassandra), to JSON-based queries (MongoDB, DynamoDB), to assembly-esque queries (Redis). This means that injection attacks have to be more customized to the target. Although, if you are able to have a coding level discussion with the developers, then you may discover that they are using a database driver which allows them to use traditional SQL queries against a NoSQL database. That could mean that traditional SQL injections are also possible against your NoSQL infrastructure. Security recommendations for a NoSQL environment also have to be more targeted. For instance, prepared statements are available in Cassandra but not in MongoDB. This is all knowledge that you can learn by digging deep into a subject and experimenting with technologies at a developer level.

Lastly, you learn to appreciate how “simple” changes can be more complex than you first imagine. I recently tried to commit some changes to the open-source project, CRITs. While my first commit was functional, I’ve already refactored the code twice in the process of getting it production-ready. The team was absolutely correct in rejecting the changes because the design could be improved. The current version is measurably better than my first rough-sketch proposal. While I don’t like making mistakes in public, these sorts of humbling experiences remind me of the challenges faced by the developers I work with. There can be a fairly large gap between a working design and a good design. This means your “simple recommendation” actually may be quite complex. In the process of trying to commit to the project, I learned a lot more about tools such as MongoDB and Django than I ever would have learned skimming security best practice documentation. That will make me more effective within Adobe when talking to product teams using these tools, since I will better understand their language and concerns. In addition, I am making a contribution to the security community that others may benefit from.

At this point in my career, I am in a senior position, a long way from when I first started over 15 years ago as a developer. However, I still try to find time for coding projects to keep my skills sharp and my knowledge up-to-date. If you look at the people leading the industry at companies such as Google, Etsy, iSec Partners, etc., many are respected because they are also keeping their hands on the keyboards and are speaking from direct knowledge. They not only provide research but also tools to empower others. Whether you are a recent grad or a senior researcher, never lose sight of the code, where it all starts.

Peleus Uhley
Lead Security Strategist


Posts, The Archives

Posted on 01-21-2015