Securing systems, data and processes at the application level is all the rage these days. With reports predicting that the market for application security products will experience a compound annual growth rate of more than 25% through 2023, it's clear that cybersecurity decision makers are embracing this trend. And when an organization pairs a focus on AppSec with the emerging practice of DevSecOps, the result is not only more secure software but also an ability to crank that software out faster.

 This is obviously an important area of consideration for CISOs, which makes it an ideal topic to explore in our new series, The CISO Speaks. This is the third installment, with previous editions having featured Q&As with Roland Cloutier of payroll processor ADP and Scott Niebuhr of space R&D firm The Aerospace Corp. For the topic of AppSec and DevSecOps, we turned to Tim Callahan, SVP of Global Security and CISO of insurance provider Aflac, to learn about his efforts to establish AppSec and DevSecOps core components of the company's security program.

 What follows is a lightly edited transcript of my email interview with Callahan:

 TK: What is Aflac's view on application security and DevSecOps? How much of a priority is application security, and to what extent has Aflac embraced DevSecOps and why?

 TC: Aflac information security and technology teams embrace the concept of application security and know that we have to accelerate delivery to support our distribution strategy. Aflac established a formal application security program more than two years ago and believes that a strong application security program is an essential component of a comprehensive security strategy. Aflac presently is beginning the planning stages of our DevSecOps journey. We have been transforming to an agile environment, and the practice is widely embraced. With DevSecOps clearly on the horizon, teams across IT, security and applications are collaborating heavily on initiatives to increase automation across the development pipeline. This collaboration will facilitate a natural transition into DevSecOps, where security is deeply integrated and largely automated. We all know that to get the speed of delivery, we have to embed security up front to avoid finding issues in a preproduction test. That only slows things down. The education we provide to development teams has pushed this forward.

 TK: What is Aflac doing to raise the level of AppSec competency in its development organization? Do you offer AppSec training?

 TC: The first, and I think most important, aspect is to create and sustain a culture of security across business and technology teams. We have done this by instituting a volunteer structure known as cybersecurity ambassadors. These folks are dedicated to championing the importance of protecting our clients and our company. Once that culture becomes embedded in all that we do, it becomes easier to tie it to the day-to-day activity. Developers and product owners become supporters of getting it right the first time. In addition to general security awareness training and campaigns, we require specialized training tailored to people’s roles in the organization. Aflac has a formal, compulsory secure coding training program that's integrated into our learning management system. Developers have to undergo required training modules pertinent to their coding specialties annually.

 TK: What AppSec tools has Aflac adopted, and how are they being used? How/why did the company choose these particular tools?

 TC: In furtherance of our principle to embed sound security up front, Aflac has adopted Static Code Analysis, Dynamic Code Analysis, Third-Party Component Scanning and Runtime Application Self-Protection (RASP). We chose these tools to ensure complete code coverage for all application changes, and to easily and effectively identify security defects in code (first party orthird party). We chose RASP to ensure that as we move more to a continuous integration and continuous delivery model, we have an additional layer of protection for the increasingly frequent production changes occurring. Tools are important, but the real key is the cultural aspects mentioned above.

 TK: To what extent do you hold your cloud partners responsible for app security, and how do you enforce/manage that?

 TC: Aflac has a robust third-party risk management program. Cloud providers and all other providers are assessed. We ensure appropriate contract language is in place. We have ongoing monitoring based on usage and risk. That’s more the mechanics. But we do see this as a partnership where we are mutually responsible to ensure security. We have to work with our providers to understand their offerings and program, and then make sure we mesh in how we use that environment. This is an important step in the due diligence process but also must be an ongoing conversation. When talking to some folks in the industry, I get the sense they believe if they move to a cloud or even a SaaS provider and they have contract language, they are good. I don’t believe that. Things change, and there must be an intentional focus on maintaining the relationship and understanding who is responsible for what. We use a cloud security provider to assist in knowing what is happening and helping to ensure a stable and secure environment.

 TK: How do you enforce/ensure adequate security in your architecture, during the design process, or when you're using open source tools or third-party components?

 TC: This gets back to the culture discussion. If we have done a good job in creating and maintaining a culture of cybersecurity, that's a big part of establishing a secure architecture. We have to build in security up front, and it takes dedicated and motivated technologists to do that. Then, we have to have agreed-upon architectural principles—those enduring principles that if never violated will lead to secure architecture. Additionally, we conduct secure design sessions that involve security architecture team members working with developers to ensure the designs are sound from a security standpoint. We also use security tools to examine for open source vulnerabilities and issues. Again, tools help, but educated people are the key.

 TK: How do you anticipate application security evolving in the years to come? Where is AFLAC placing bets in this arena?

 TC: We try to be predictive but it is always predicated on what we know now and how that affects our future view. We do see that brokered APIs will likely become the predominant way that applications communicate, reducing the attack surface dramatically. Security will move into the application layer, and things like Zero Trust will provide more granular restrictions to sensitive data. Continuous integration and continuous delivery will continue to gain momentum. Finally, automated tools that identify vulnerabilities in code at multiple stages in the pipeline will increase developers’ awareness of security risks with their code and allow security policies to be enforced earlier in the CI/CD pipeline.