AI Security Table

Imposter Syndrome is when a person feels inadequate despite their accomplishments. Not unique to the field of cybersecurity or even software development, imposter syndrome can affect any professional as they advance and grow in their area of expertise.

Matt and Izar, both seasoned security professionals, openly discuss the dichotomy between their intellectual achievements and the emotional weight of feeling like they don't belong. They touch upon the challenges of presenting at conferences, where the internal dialogue of self-doubt might be at its loudest, yet they've learned to project confidence. 

The conversation also highlights the importance of understanding one's worth, emphasizing that it doesn't stem from external validation or the opinions of others. The hosts each share personal anecdotes, such as moments when they felt most vulnerable on stage, and how they've learned to navigate these feelings over time. 

This podcast serves as a candid exploration of the imposter syndrome, offering insights and encouragement to professionals from any field who might feel the same way.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

The Security Table team dialogues about the importance of data and metrics in understanding and communicating risk. After Matt defines ROI, Izar emphasizes that while data is crucial, it doesn't always come in numerical form. Instead, risk can be expressed in various ways, such as trends, and doesn't necessarily need to be quantified in traditional terms. Chris stresses that executives need tangible metrics and data to make informed decisions, especially when communicating with legal teams and other stakeholders.

They then talk about visibility and understanding the attack surface. Izar explains that the attack surface represents an organization's exposure to potential threats. The goal is to provide a comprehensive picture of the organization's vulnerabilities and the measures taken to address them. Instead of inundating executives with technical reports, Izar suggests telling a story that conveys the essence of the risks and the steps taken to mitigate them. Chris, however, emphasizes the importance of concrete data and the challenges executives can face in understanding technical nuances.

Lastly, the dialogue touches upon the real-world implications of threat modeling and its ROI. Matt Coles highlights the potential legal and business repercussions if things go awry. The discussion underscores the evolutionary nature of threat modeling, with Izar noting that while one might start with limited expertise, continuous learning and adaptation lead to improvement over time. The overarching theme is the balance between technical details and business-oriented communication, ensuring that executives understand the value and impact of threat modeling initiatives.

Links referenced:

• US Executive Order 14028 on cybersecurity - https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
• CISA, Secure by Design, Secure by Default - https://www.cisa.gov/securebydesign
• Secure Software Development Framework (SSDF) from NIST - https://csrc.nist.gov/Projects/ssdf

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

Jim Manico joins Chris, Matt, and Izar at the Security Table for a rousing discussion on his Threat Modeling journey. They also learn about each other's thoughts about DAST, SAST, SCA, Security in AI, and several other topics. Jim is an educator at heart, and you learn quickly that he loves application security. Jim is not afraid to drop a few controversial opinions and even a rap!

Jim discusses the importance of static application security testing (SAST) and how it is becoming increasingly important in application security. He argues that SAST is a powerful tool for detecting vulnerabilities in software and that modern SAST tools can work at DevOps speed. He makes his case for why he believes SAST will be the ultimate security tool in the future.

Jim also talks about the potential of AI in the field of software security, particularly in the area of auto-remediation for SAST findings. He believes that with good data and models, AI-powered remediation engines could revolutionize the industry.

The episode also delves into threat modeling and its role in software development. The participants discuss the importance of identifying security issues early in the development process and the return on investment (ROI) of threat modeling. Jim emphasizes that threat modeling should focus on identifying issues that static analysis tools cannot easily detect, such as access control vulnerabilities. 

They conclude with a discussion on the "shift left" movement in software security and its potential benefits and challenges.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

"Secure by Design" has garnered attention with the release of a document by CISA. What does it mean? How does it fit with Threat Modeling? And do you know if Secure by Design will answer our need for secure software?

"Secure by Design" means a system is designed with secure principles. The system should come pre-hardened and pre-secured, ensuring users don't have to configure it for security after installation. On the other hand, "Secure by Default" means that the system is configured correctly for security right out of the box.

The hosts explore what it means to be secure by design. Systems can be implemented with security principles rather than relying on users to configure settings post-installation. Matt raises the concept of "de-hardening" guides for compatibility and other situations. But Chris Romeo strongly opposes the idea, fearing it might provide a roadmap for undoing the security measures put in place.

They also discuss how Threat Modeling fits with Secure by Design as a guide at the beginning and in the verification process. The episode concludes with the hosts emphasizing the importance of continuous threat modeling and the need to stay updated with the evolving security landscape.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

What happens when engineers transform into security champions? Is this beneficial, and what are the implications of this transformation? Izar reveals his transition from a naysayer to a supporter of security champions, and Chris and Matt seek to understand his current position. They explore the position of Security Champion and discuss the components of a good security champion program.

Matt defines security champions as developers with influence who can be a bridge between security and engineering. They receive advanced training and bring resources to their team to lead them to effective threat modeling. While security champion programs may have potential pitfalls, such as overloading team members, good security champion programs should benefit the individual and the business. Chris emphasizes the importance of providing opportunities for growth, learning, and networking to make the program appealing to potential champions.

With the potential issue of champions leaving an organization, they highlight the need for companies to keep up with salary expectations as champions grow in their roles. They also touch on the challenge of preventing security champions from being disliked by their team once they transition from being developers.

There are several resources for those interested in building a Champions program, including Dustin Lehr's Security Champion Success Guide and Chris Romeo's Security Champion Framework available on GitHub.

The episode concludes with a call for listener feedback and input, emphasizing the hosts' desire for an interactive and engaging conversation with their audience.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

There is a relationship between security professionals and engineers. Explore the possibility of engineers disliking security personnel and how security professionals can improve their relationship with engineers.

Security professionals need to be empathetic, have strong soft skills, and be able to influence and embed themselves within the engineering team. Resource management is essential, and avoiding engineers feeling like security is always giving them an over-the-shoulder look. 

Being part of the engineering team and understanding their world is vital to being a security professional that engineers don't hate. It is challenging to sell security as insurance to engineering leaders who may not see the value in investing time and resources.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

What is security posture? Izar was at a conference in Amsterdam, where he was asked to define security posture and how to measure it. Is security posture qualitative or quantitative, and can it be compared across teams, organizations, and departments? This led us down this rabbit hole; what is security posture, and is it even possible to measure?

Security posture is multi-dimensional, differentiating between organizational and system security postures. Security activities that are reasonable to a company's level of risk acceptance are essential. Leadership changes could impact security posture; the departure of a CISO, for example, doesn't immediately affect the security posture as the policies and experiences built up over time remain.

Tools and processes assess security posture. An organization's security posture doesn't necessarily reflect the system's security posture. You must understand where a design is starting regarding security and where it is now.

The episode concludes with a call to listeners to share their thoughts on security posture and contribute to the ongoing discussion. The hosts express their interest in learning from different perspectives and experiences in security.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

The big question is if it's possible to lose the application security team and move all the functions directly into development.

What are developers' roles in application security (AppSec), and what challenges do they face?  We delve into developers' responsibility in ensuring security, despite not always having the necessary tools or training to do so effectively. 

We discuss "shifting everything left," which refers to integrating security earlier in the development process. We express concern that developers are being burdened with increasing responsibility without being given the power or resources to handle it effectively. This is referred to as the "inverse Spider-Man thing" - with great responsibility should come great power, but this isn't always the case in AppSec.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

How do you determine what constitutes "reasonable security" when evaluating vendors? Is “reasonable” a measure of compliance to a set standard? Is it reasonable to expect mature threat modeling practices? Some expectations are too high to be reasonable, but the minimum standard that both parties agree upon doesn’t seem like enough.

Join the hosts of the Security Table as they discuss the importance of a reasonable security standard, one that both a vendor and the buyer can agree upon.

Izar bemoans the vetting process for software vendors that can be overburdened with paperwork and checkboxes, but still lack confidence in a product’s security. Can we do better? He asks Matt and Chris what information or assurances vendors can reasonably provide to convince buyers that they truly understand and prioritize security.

Chris proposes evaluating people, process, tools, and governance as a starting point. Matt raises concerns about needing to satisfy the concerns of the end customer and internal teams and leadership. Threat modeling is proposed as a basic starting point. But, is threat modeling just a bare minimum, or is it the reasonable standard both sides of the discussion can be happy with?

The team discusses the importance of seeing the pipeline of any product being considered. 

What is reasonable? A threat model, documentation of that model, and an invitation to read and ask questions about the described process. The threat model needs to cover what and how software is built, as well as deployment into production. That is enough. That's reasonable. Is the team’s conclusion reasonable? Listen along, and watch for the upcoming discussion on LinkedIn.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable

Certificate pinning is a security measure used in computer networking and something Chris candidly admits to his lack of understanding.

Matt and Izar explain certificate pinning, a client-side operation that adds an extra layer of security to the Transport Layer Security (TLS) protocol and ensures that the client application checks the server's certificate against a known copy of that certificate.

The discussion leads to a reflection on the vast amount of knowledge required in cybersecurity, emphasizing the importance of continuous learning and the willingness to admit and fill gaps in one's understanding. Engage in further research and discussion, and realize cybersecurity is a "never stop learning" discipline.

Follow AI Security Table:

➜ Home: https://securitytable.ai/

➜ X: https://x.com/SecTablePodcast

➜ LinkedIn: https://www.linkedin.com/company/ai-security-table/

➜ YouTube: https://www.youtube.com/@AISecurityTable