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).
