Sometimes the hardest step to take is the first. If you are facing a non-existent Applicaiton Security (AppSec) Program, or one that needs a reboot, here are some suggestions on how/where to start.
Beginners Advantage
The first mistake that can be made when there is no formal AppSec Program is to fail to take advantage of the existing situation. If you have no program, the Development Team are the only ones responsible for security. Long-standing programs struggle to establish this because they have long since taken Security out of the hands of the Development Team.
The reality of an AppSec Program is that its primary function will always be Assurance. Rarely, if ever, have I observed an AppSec Engineer directly contribute to the application lifecycle in any other way. Many do not even have Software Engineering experience as they are usually plucked from Infrastructure Security. This is corroborated by the many job listings for AppSec, which list Penetration Testing skills and certifications as requirements.
Because this background is common, development teams are rarely recognized for established security practices. Any existing Development Team will be performing activities devoted to fixing flaws and reacting to incidence as well as many other activities essential to the success of an AppSec Program.
Assertion
By taking advantage of this initial strength in Assurance, an AppSec program can assert itself as an aid to achieve higher standards. The focus of those higher standards is obviously Security, but also with an understanding that broader attributes of quality and maintainability are directly related to repeatable security enhancement. There is an obligatory relationship between Security and Quality, where Application Security Programs can never productively be more sophisticated than Quality Assurance (QA) and Control (QC).
Based on this approach, the AppSec Team should identify and acknowledge areas where the Development Team are doing well. Then they should work together to identify ways in which small changes can be made to emphasize security or to bring existing practices into full compliance with security definitions.
Footprinting
Security frameworks can be highly valuable in the initial stages of an AppSec program. These come with tools for framing context, setting goals and tracking progress. Frameworks are not a one-size-fits-all solution. Development teams will differ wildly. Learning from implementing a security framework will forever influence them, good and bad. So be careful about forcing a framework into a situation where it does not fit.
One personal favorite is OWASP SAMM. It establishes a vocabulary and definition system that can be socialized among development teams. It also has a questionnaire that can be used to footprint the existing development process and then be used to track progress. Early on SAMM can be used to identify practices that partly match the purpose defined and signify low investment gains toward maturing the Security Program.
Establishing Roots
Certain domains of OWASP SAMM require heightened interaction between AppSec and Dev teams. Those are the domains of Design and Verification. Verification is a SAMM domain that can be initiated and driven though automated tooling until the output reaches a level where more manual Verification processes can be implemented to find less-common issues.
To quickly establish a valuable feedback flow from Verification, implement automated Application Security Testing tools. Then create a process for adding Development work items from these tools. This should closely model how flaws from QA flow. It may be necessary to enhance the QA process or even the development process to accommodate multiple sources.
It is good to note that up to this point progress reporting to upper management should consist entirely of the progress of Application Security implementation. It should have nothing to do with vulnerabilities or flaws until the Development Team has had several cycles to get acquainted with the information and how to address these sorts of issues. There should also be an additional timebox to work through some initial issues. This additional buffer should be worked into the plan early. This places the AppSec Team in an adversarial posture toward vulnerabilities and not the Development Team.
Breaking Ground
Once the Verification process has started it is time to establish elements from the SAMM Design domain to direct the implementation away from common pitfalls and major catastrophe. This may be where establishing the AppSec Program gets difficult, especially if there is a lack of development background on the Security Team. This is a much simpler task when the previous steps have been performed in concert with the Development Team. It may be that when done well, the Development Team will seek out the AppSec Team with the desire to integrate security methodologies in the Requirements, Architecture and Design phases of development.
At this point the team can simply start by asking questions to introduce security to requirements gathering or backlog grooming as well as architecture. It is also useful to introduce Threat Modeling via the Four Question Framework:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
Growth
This is the point where meaningful conversations can happen about the AppSec Program’s maturity. Next, work on the SAMM domains of Operations and Governance to bolster a holistic Application Security Program. Start scoring using the OWASP SAMM questionnaire on a regular interval to track the program’s progress.
I hope this inspires new Application Security Programs to progress down a path of logical development with an eye to embedded cooperation with Development. There are times when working in Security can seem hopeless unless we look ahead to maturing the methodology. It is not about “Shifting Left” to force reinvented processes on development. Never forget that Software Development was established long before someone decided to excavate security concerns and assign them to AppSec. Reintegrating them is the best way to gain quick traction and lasting productivity.
The Code Snob 