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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

"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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

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 OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

What is privacy, and how does it intersect with security? We are joined by our first guest, Ally O'Leary, a privacy compliance expert. Ally works for a consumer electronics company, ensuring compliance with global privacy laws and acting as a data protection officer.

The episode delves into the intersection of privacy and security, with Ally explaining how these two areas often go hand in hand. She emphasizes the importance of understanding the definition of personal information and being aware of where such data is stored within a company's systems.

A significant part of the discussion revolves around why security and privacy are two different functions within a company. Ally explains that privacy is a relatively new concept for most companies, often triggered by regulations like the GDPR. She also mentions that privacy often becomes part of the legal function due to the close work with attorneys to interpret laws.

The conversation also touches on the challenges of data governance and the importance of proper data ownership on the business side. Ally highlights the need for regular reviews of data flows and audits to stay on top of data governance.

Towards the end of the episode, Ally advises security professionals on when to involve privacy experts in their processes, especially during the development life cycle. She encourages security professionals to notify their privacy colleagues about any projects or initiatives that might impact systems containing personal data.

Overall, the episode provides valuable insights into the world of privacy compliance, the relationship between privacy and security, and the role of data governance in protecting personal information.

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

Guard rails and paved roads -- how do they fit together in application security?  Guardrails are security tools in the pipeline that help ensure the software doesn't drift too far from established standards. These guardrails allow developers to maintain their creativity and flexibility while building features that ultimately go to the customer.

Paved roads are platforms that developers can build on top of without having to worry about aspects like identity and access management. Paved roads and guardrails funnel developer activity without breaking their freedom to do what they need to do

Automation is critical in maintaining guardrails and paved roads. Automation allows for the creation of new structures and ensures that existing structures function as expected.

The episode concludes with the hosts expressing their commitment to driving down the paved roads, building more security guardrails, and making everything secure by default.

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!