Building Immunity at AppSec Insertion Points
The fundamentals of a formal, effective application security plan should start with business objectives, tools, processes and most of all, data, with the primary driver for securing applications focused on protecting data.
While it is important to surgically address the insecurities in a mission-critical application, it is equally important to continuously upskill the development and security teams, and create a culture where security is not looked at simply a ‘check-the-box’ item.
According to Setu Kulkarni, vice president of strategy at WhiteHat Security, the first step is to identify the right inflection points for injecting application security.
“CISOs need to recognize that no SDLC is built the same and no application is at the same level of maturity within its life cycle,” he said. “We have learned that testing applications continuously in production is critical to identify the real, exploitable vulnerabilities that create the maximum risk of being breached in production.”
Kulkarni noted one way to (almost always) ensure that security does not become an afterthought is to “top & tail” – in other words, make sure that your team gets a voice when the exit criteria is being defined during the requirements phase, and make sure the team is testing in pre-production and production.
“Everything in between is really a negotiation based on the maturity of the SDLC and the application itself. The most consequential best practice is to ensure that the Dev, Sec and Ops teams get accurate and actionable insight from the AppSec tests that are executed,” he said. “After all, the only way to eventually have security operate at the speed of DevOps is through some level of automation, and the efficacy of automation is directly proportional to the accuracy of the data used to drive the automation.”
Doug Dooley, COO of Data Theorem, pointed out that the business driver for AppSec is about privacy, trust and reputation that is directly tied to the brand of those who build and publish the applications.
He noted traditional AppSec testing focused on static and dynamic application security testing, including static application security testing (SAST) and dynamic application security training (DAST).
“However, with a more modern application stack, AppSec programs are starting to factor in third-party risks introduced by open source and software development kits, covered by software composition analysis,” Dooley explained.
Further, cloud-native applications make infrastructure services just another software extension of the application buildout, so many AppSec programs increasingly add cloud security tools, such as cloud security posture management (CSPM).
Dooley also pointed out that automation is key to the best AppSec testing approaches, because manual pen testing can no longer keep up with agile development process and the culture of DevOps.
When it comes to building a culture of application security within the organization – starting with the CISO on down – he noted CISOs have to first agree that software applications are driving most enterprises these days.
“Every business is now in the software business, whether they like it or not,” Dooley said. “Further, the DevOps teams, not traditional IT, are now the enabling force for digital transformation in most businesses. IT security needs to be an ally, not an adversary, to DevOps.”
Dooley explained that by using an automated AppSec approach with modern tools that integrate with the existing CI/CD pipeline, it increases the chances that the culture of AppSec will be welcomed with open arms.
“Security can make the DevOps trains run faster and smoother with improved safety railing that keeps applications more secure and running on time,” he said.
Dooley said the mindset within application security needs to shift out, away from blocking and denying and toward bug fixes, features and catching the next release.
Once security adds value to the DevOps team with automation, it will start to become a valid source of new “tickets” that gets added to the bug and feature backlog, and as daily and weekly releases occur, security will just be another set of quality and feature improvements constantly being added to applications.
Dooley explained that traditional AppSec has historically been a manual, break-stop-driven approach to security; when problems are found, the idea is to stop the train and fix the problem.
“For the most part, manual AppSec such as pen-testing vulnerabilities and code hygiene escalations found by SAST tools are mostly ignored by DevOps teams,” he said. “Security is factored into DevOps via DevSecOps, when the AppSec tools, processes and people are fluent in shipping code on time and often. The train doesn’t really stop with DevSecOps, and the AppSec program has to embrace this approach.”
Michael Isbitski, technical evangelist at Salt Security, pointed out the building security in maturity model (BSIMM) and open web application security project (OWASP) software assurance maturity model (SAMM) are good reference materials for understanding different components of application security programs.
“Most modern applications are made up of many web APIs under the hood,” Isbitski said. “Securing all these APIs is becoming an increasing area of focus for organizations as part of their application security programs.”
Isbitski said it is also helpful to think of vulnerabilities or weaknesses as types of bugs, quality issues or defects.
“This has amplifying effects for security and non-security processes and can help build that culture of application security awareness amongst teams,” he said.
