Security Wins Only When Institutionalized – Here’s Why! ⎥ Kevan Bard

Discover insights from The Elephant in AppSec episode with Kevan Bard.

Security Wins Only When Institutionalized – Here’s Why! ⎥ Kevan Bard

Welcome to the written recaps of the Elephant in AppSec, the podcast to explore, challenge, and boldly face the AppSec Elephants in the room.

Today, I'm joined by Kevan Bard, Director of Product Security at Morningstar. With 20 years of experience in information security, Kevan has helped shape security practices across various organizations. He’s passionate about building blue team careers, with a focus on recruiting, mentoring, and staff development.

In this episode, we explore:

  • Why security needs to be institutionalized to win
  • How the role of Product Managers should evolve to integrate security into their processes
  • Why storytelling is crucial in security education
  • Why the term ASPM is overrated, particularly because its true value isn’t being marketed effectively

    💡
    Listen now on Spotify and YouTube. The Elephant in AppSec caters to all: Whether you prefer listening, watching, or reading, we have something for everyone.

    Security Should Be Institutionalized, Not Dependent on Champions

    One of the central themes Kevan discussed was the need for security to be ingrained into the fabric of product teams rather than relying on individual “security champions.” He emphasized the importance of making security a fundamental part of the organization’s structure, rather than depending on one or two people to carry the burden.

    What we need is to institutionalize built-in security throughout the system development lifecycle.

    "Security only wins when it’s institutionalized. I learned this from my colleagues at Morningstar in our ESG team (Environmental, Social and Governance analysis) , which really helps us identify leading firms that make great long-term investments. So what they have told us is that the objectives of ESG need to be institutionalized. You can't just have a champion, a extremely persuasive person, or a very receptive technology leader. That's similar to a hero pushing a massive boulder up a hill every day. And that's going to work for you every day until that hero is no longer available. Then your security is just going to backslide. You need to actually institutionalize. And why I think that's going to live in product teams is that product teams at this point in time across many industries, including here, they are institutionalizing new ways to work. They're building out developer portals. They're getting access to feedback that's security feedback or bug feedback that's integrated into their work. They outnumber us vastly. So they're building new institutions of how to develop software at a very fast pace. We are relatively slow. We, the security practitioners and leaders, are relatively slow. My belief is there's a possibility here, there's an opportunity to have that security institutionalization in the new ways that people are doing the development work."

    Product Teams as the New Frontier

    How will it look like in the long term?

    This is what Kevan mentions: "But what it looks like is that security requirements just appear in your design documents. You don't schedule a time. You don't raise your hand and say, hey, I'm making some security relevant changes here in my product or my project. We will have almost immediate feedback."

    The Role of Generative AI

    Kevan spoke enthusiastically about the possibilities of generative AI, stating:

    So we talked about how it's not going to require effort on the part of product teams to get their feedback, to get their requirements. They don't schedule time with someone. It's not an asynchronous process. We really need to build it in. And this is something that I think is actually enabled by generative AI, right? I think the future is here; it’s just unevenly distributed.”

    Kevan also expressed his belief that in order for AI-driven security tools to gain widespread adoption, they must first prove themselves with early adopters. "They need to be able to develop this way and have security work performed this way so that they can... basically get the first adopters to agree, and then the rest of us will follow," he said.

    Empowering Non-Security Teams with Security Knowledge

    Kevan argued that organizations should strive to educate at least one person on each development squad in high-quality security practices. “We need to give the general population of our organizations the best security education," he noted, suggesting that security training should be compelling and hands-on, offering real-world scenarios rather than theoretical knowledge.

    Kevan suggests that this education should involve "simulations of a broken environment and a careful, thorough walk-through of how you would fix it."

    He also believes that such education can spark curiosity and problem-solving skills, especially among developers, who often enjoy the challenge of security as a puzzle. “A lot of people in development want to do security because they think of it as puzzles and problem-solving,” he observed.

    Internal Marketing as a Key to Security Success

    Where security must be ingrained across all teams, Kevan argues that the ability to communicate the importance of security within the organization can make all the difference. He puts it plainly:

    Literally the ingredients, for this big monumental change that we're embarking on that others I think should embark on is internal marketing. Internal marketing skill is a make or break ability for your security and privacy team, 100%.

    How the Way of Conducting Threat Modeling Might Change

    We also discussed a bit about the potential for enterprise architects, specifically those who are moderately trained and diligent, to play a critical role in threat modeling, especially for large greenfield products and migration projects:

    “Threat modeling by a moderately trained and diligent enterprise architect is definitely possible for at least large greenfield products and migration projects. It has the advantage of filling the designer's thoughts with the security objectives that are relevant for the system design. No translation necessary! The main point is that many security flaws are just another kind of bug. That could be a bad feature design with a business logic flaw. Or it's a broken implementation of technical safeguards. Or it's third party code that is unpatched and easily exploited. The point is that putting security fix work in every PR and every scrum board (or developer portal if you need to be the coolest cat) is the best way to integrate this into the business of development. Scrum masters and other team leader servants will need support in articulating the right attitude toward security-related work. There is a lot of cynicism to overcome."

    The Need for Automation in Security Compliance

    Automation in security compliance is becoming increasingly essential as organizations strive to keep pace with the rapid evolution of technology and the growing complexity of security requirements. Kevan highlights the necessity of automation, stating, "You need to be able to create your own audit trail of your own program. At least for your PCI environment."

    Kevan also envisions automating compliance tasks by turning them into software, which simplifies and streamlines the process: “Everything is becoming so standardized, everything is an API, we could have policy as code, you know, we could do compliance, we could move some compliance work into software, right, and full automation.”

    The Role of Security Education in Shaping Careers

    Security education plays a crucial role in shaping the careers of individuals within an organization. Kevan notes the potential of early career individuals, stating, "I no longer underestimate early career people. I think people who have curiosity and that energy can achieve amazing things." By investing in security education early in an individual's career, organizations can harness this potential and cultivate a workforce that is both knowledgeable and motivated.

    Moreover, Kevan highlights the impact of onboarding experiences on security awareness, stating, "The people who had a bad onboarding... the likelihood of you becoming an insider risk is like 500% more." This underscores the importance of integrating security education into the onboarding process to mitigate potential risks and ensure that new employees understand the security landscape of the organization.

    On ASPM

    Kevan Bard had some strong opinions about the concept of Application Security Posture Management (ASPM) and its marketing:

    I'm going to throw the term ASPM under the bus. Which is kind of ironic because we just invested in what you could call an ASPM. But I don't find the term and the way it's being marketed to be very helpful. Applications live in environments, so the ASPM that we chose includes cloud security vulnerabilities, network vulnerabilities, we did not just focus on application vulnerabilities. It's kind of a unified, almost like a fusion center for vulnerabilities and misconfigurations, right? The problem is that the real value of an ASPM isn't even communicated in the one-pager. The one-pager says, you know, kind of wild claims like, we'll help you identify previously unknown flaws or we'll give you a clear, simple roadmap to becoming fully secure. It's a very big claim.
    I mean, what it should do is it should transform your security data from scans and even pentests and all of the assessments that are happening like all the time. It should be able to turn that into actionable intelligence. Who needs to be the fixing team? That's the first thing that an ASPM needs to supply, right? Maybe which items are we going to work on now versus we got a parking lot these for some reason and somebody's going to accept the risk of that. That's obviously going to happen when you have over a million open flaws in an enterprise, which they all do. Some things will get in the parking lot because, you know, valid reasons. We just want somebody who's responsible management to say I accept this. I acknowledge this. I accept this. End of story. It's not that complicated.

    In his view, ASPM tools must be able to contextualize vulnerabilities properly, not just identify them:

    You have to contextualize your vulnerabilities, meaning you have to figure out where a combination of exposure, exploitability, impact, and maybe data and maybe identity, all of these factors combined to create, this is actually a critical issue. This needs to be solved within the next seven to 15 days. Right? Like that, that is what your ASPM should give you. You know, filtering, contextualizing.

    Conclusion

    In this episode of The Elephant in AppSec, Kevan Bard shared some great insights about where security will lie within organizations. He stressed that security should be part of the organization's DNA, not just dependent on a few champions. Kevan also talked about the importance of hands-on security education, effective internal marketing, and the potential of AI tools to automate and streamline security processes. His thoughts on ASPM are worth listening to from these vendors, pointing out that the tools need to focus on giving actionable, contextualized security data, not just promises ;)

    Other relevant podcast episodes