Peleus Uhley is lead security strategist at Adobe
As security moves more increasingly into the national spotlight, the need for security engineers and experts has never been greater. For those interested in security researcher positions, my best 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.”
Pure security researchers have often seen only the failures in the industry. This can lead them to assume vulnerable code is always the product of apathetic or unskilled developers. If they have never been exposed to large-scale development, then they don’t have a robust understanding of the complex challenges that face developers in secure code development.
A researcher can’t be effective in a development organization if he or she doesn’t appreciate the challenges on the other side of the table.
People with development backgrounds can also, often times, give better advice. Let’s take a look at NoSQL databases versus SQL databases. Simply put, SQL and NoSQL databases both collect, organize and accept queries for information, therefore both are susceptible to malicious code injections. Due to this, when NoSQL databases became popular, people were quick to predict that NoSQL injection would become as common as SQL injection. At a high level, that is conceptually accurate, however developers know that it’s not that simple.
If you dig into NoSQL databases, you quickly realize that there are a wide variety of query formats, from SQL-esque queries (Cassandra), to JSON-based queries (MongoDB, DynamoDB), to assembly-esque queries (Redis). Therefore, security recommendations and tools for a NoSQL environment have to be targeted to the individual server.
Your testing tool has to have injection attacks that are in the format of the specific database. You can’t blindly recommend prepared statements since they are not available on all platforms. Encoding recommendations for data will be specific to the database type, as well. This is all knowledge that you can learn by digging deep into a subject and experimenting with technologies at a developer level.
Lastly, developers learn to appreciate how “simple” changes can be more complex than imagined. For example, I recently tried to commit some changes to the open-source project, CRITs. While my first commit was functional, we’ve been going through several alternative designs in order to determine the best approach for the project. The team was absolutely correct in rejecting my initial changes because the design needed to be improved so that it could be sustainable over the long term.
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. This experience 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 more than 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 and iSec Partners, 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 a recent grad or a senior researcher, never lose sight of the code, where it all starts.