AppDev To AppSec - The Transition
In 1978, the term Imposter Phenomenon was first introduced in an article by Dr. Pauline R. Clance and Dr. Suzanne A. Imes. It articulated that the introjection of societal stereotyping and our own internal bias lead to this common barrier to personal growth we see today. That is, even with great accomplishments we tend to look at ourselves as imposters. A few months ago I asked a few friends what does it take to be an Application Security Consultant? The answer surprised me.
When I was an Application Developer, I had a conversation with my Chief Information Officer (“CIO”), who was also the Chief Information Security Officer (“CISO”) at the time. We discussed my prior experience, my current role, what I enjoy working on, and his career path. He referred to his skills today as broad; he is now a generalist. He reminisced about the days where he was the specialist. Today, he relies on his team of experts to provide him with the information he needs to make the right decisions and trust they will handle the critical smaller details.
Every expert with whom I spoke regarding the transition to Application Security, each with different levels of security expertise, said I already had the skills. However, each had their own caveat:
System Administrators were overwhelmingly knowledgeable about Network Security, but wouldn’t know the first place to start to create the web service that sits on their server.
White Hat hackers who can find and exploit vulnerabilities, generally lack the experience with software development to recommend a solution.
Software Developers who can spin up a web service from scratch with their morning coffee, but have been conditioned over the years to sacrifice security for time-to-market.
In other words, each person had their own level of abstraction from the minutia, and each had trust in the underlying infrastructure and applications supporting their processes. Each one was a valuable asset to the team.
A Branch of Application Development
Computer Science is just as complex as Medicine, and in Medicine, you have specialists, e.g., Pediatric, Geriatric, Gastroenterologist, etc. When a child is developing, the parents consult with specialists. Primary Care providers consult with other doctors and sometimes refer their patients to a provider with more experience in that specific field. Application Security is just that; a specialty of Application Development.
We triage bugs and requirements much like how we triage patients in an emergency room; highest risk gets priority. A critical patient is going to come first over a patient who walked into the clinic. A security vulnerability that has a low risk of being exploited does not take precedence over a critical ticket when the application is down. I have learned that Application Security Consultants are those specialists who help identify the root cause of a vulnerability and provide guidance on how to resolve the concerns.
Who is an Application Developer?
To clarify, an application is any tool created that uses logic to perform a series of coordinated tasks that benefit a user or a process. Therefore, a person who creates something that adds value to a method, using a programming language, is an Application Developer. The experiences and tenacity for quality are what set a new Developer apart from a Senior Developer.
I have had many discussions with fellow developers who experience imposter syndrome. Just because you are new and inexperienced does not mean you are not a developer. What do they call a person who graduates last from medical school? A doctor. If you have learned the basics and can produce results, you are a developer.
So, all you accountants, excel gurus, and office wizards out there creating tools to save yourself and your co-workers time, consider the field of Software Development - you are already doing it in some capacity.
Just like a growing developer, one can only learn and understand a limited amount of information at one time. When I first began developing tools, I was creating scripts that saved me time or improved the product quality. Over time I started to break the scripts down into similar functions, classes, interfaces, and eventually added graphical interfaces for other users. Those mistakes early on in the design phase made for headaches and refactoring down the road, but I took that knowledge to the next project; not going to make that mistake twice, right? Over time you become a strong developer by learning from those mistakes than using and sharing that knowledge with other developers. That’s where code reviews are invaluable.
Four Eyes are Better Than Two
The code will evolve through peer reviews and maintenance by a mix of developers. Peer reviews are an integral part of the development process, especially for a junior developer. This step is where you create the implementation for the solution and have a peer provide feedback. As a junior, you are receiving feedback from mentors who have seen it all and can easily explain the proper way to implement that interface or how to refactor that method best. As a Senior, you learn by having to properly articulate why something should be done a certain way, or you learn a new way to solve the same problem; win-win for both sides.
An Application Security professional is just another senior member of the team, but instead of focusing the code review around results they focus specifically on the security and stability of the application from malice. A senior application developer will suggest you filter the results by the provided ID. The application security professional will review that updated method, but mark a finding because you do not confirm the ID provided by the user input is the same user.
Do It Right Or Do It Twice
Most businesses are the same. When given a choice between speed, quality, and cost for any project the default is always speed and cost, ergo make a solution with no budget, and it was due yesterday. Unless there is a requirement, developers are not going to “waste” time on certain aspects of development if they are not appreciated or desired by the end user. Improved security for a higher cost and slower time-to-market is a hard sell most of the time.
The best way to grow your skills in security is to make security a priority, perform your own penetration testing, and consider consulting an expert to show you things you don’t know - because you don’t know everything and neither does your team. Ask questions and don’t accept the usual “it’s the way we have always done it” as an excuse. Be proactive to security threats rather than reactive. It will not only help your career, but it will make your employer less vulnerable. A brand takes a lifetime to build and seconds to ruin.
It’s cheaper and faster to make the right decisions now than to try to fix issues later with half your clients.
If you are currently participating in peer code reviews, which you absolutely should be, and have worked on a production application, then you already have a solid foundation for a job in Application Security. Research and learn; incorporate what you learn into your own best practices. Do your due diligence for only you have the responsibility to control the quality of your work.
As stated before, security may not be a priority to your employer, or for your clients. You will have to take the initiative yourself or be persuasive. If you are a developer interested in security, consider applying for a job. The worst thing that could happen is that you become a better developer and makes some friends along the way. Don’t let your own internal bias and external influences stop you from taking the next step in your career.