SecuriTea Time Ep 4 | Cyber Roulette: Playing with Digital Risks

Greetings, everyone! We're thrilled to welcome you to another riveting installment of the SecuriTea Time podcast.
Today, we have the honor of featuring Farshad Abasi, the mastermind behind Forward Security, headquartered in British Columbia. With a wealth of experience in software security, Farshad is a seasoned expert in the field.
SecuriTea Time is your ticket to exploring the captivating journeys of individuals in the realm of risk and compliance. Our guests come from diverse backgrounds, and I must say, delving into their narratives is both enjoyable and profoundly enlightening.
So, grab your favorite brew, and let's prepare for a discussion that's as invigorating as it is informative.
For the full podcast, click here.
https://youtu.be/b3RzS0SWR1s
Now, let's get right into this exciting episode of SecuriTea Time.
Nicholas Muy: Help us and our listeners learn a bit more about software security.
Farshad Abasi: Software security was often neglected given the traditional focus on network and infrastructure security. However, this has changed due to the advent of APIs and digital transformations. Nowadays, software is a prime target for cyberattackers, especially when it's exposed beyond a company's usual boundaries.
Nicholas Muy: Firewalls and infrastructure used to be the main concern for a long time. Today, software takes precedence over infrastructure for many companies, including ours, which is primarily a SaaS business. In the past, older infrastructure required more effort to secure. We use Cloudflare for our front-end WAF. This allows us to focus on areas that may not receive as much attention. What are the typical oversights in software security?
Farshad Abasi: The most significant challenge lies in the fact that security assessments for software are often conducted by professionals with a background in network and infrastructure security. Traditional penetration testing methods, effective for infrastructure, may not work well for new custom software that lacks known vulnerabilities. Many security vendors offer only traditional penetration testing and may not grasp the intricacies of software. This can lead to a false sense of security. To conduct a comprehensive software security test, you need to incorporate source code reviews, design reviews, threat modeling, and manual inspection. Fortunately, guidelines are emerging to encourage thorough software testing, aligning with OWASP recommendations.
Nicholas Muy: It seems there are various aspects to consider when it comes to software security, including manual review, scope testing, source code assessment analysis, threat modeling, and penetration testing. Given these multiple dimensions, is there any guidance on prioritizing among these, considering that not everyone may have the expertise to cover all aspects effectively? Additionally, how can organizations bridge the potential gap between developers and security engineers, who may specialize in different areas of software security?
Farshad Abasi: In terms of prioritizing the various aspects of software security, there are some key considerations. Design reviews and threat modeling are valuable, but they often require skill sets that may not be readily available within a development team. Efforts are underway to create tools that can simplify and democratize these processes, making them more accessible to developers. However, without such tools, options like Microsoft's threat modeling tool may not be developer-friendly, as they can be time-consuming and produce confusing results.
Based on my experience in application security over the last 15 years, I'd say that, on average, an application typically has about 20-25 threat scenarios. These are not vulnerabilities themselves, but combinations of vulnerabilities that can be used to form an attack pathway. Design reviews tend to uncover around half of these threat scenarios in an average application, with the other half discovered through penetration testing.
Interestingly, high- and medium-risk issues are often found during design reviews, whereas penetration testing tends to identify medium- and low-risk vulnerabilities. This underscores the importance of design reviews in the software security process.
However, it's worth noting that while design reviews are valuable, they do require a certain level of skill and expertise. Developers can be trained to conduct basic design reviews themselves, which can be particularly beneficial for addressing low-hanging fruit, as roughly 80% of security issues fall into this category. This mentorship and training approach can help developers become more capable of identifying and mitigating security risks within their code.
Nevertheless, it's essential to recognize that both security and software development are vast domains, and while developers can handle the basics, they may not be expected to reach the expertise level of a dedicated security professional. In those cases, subject-matter experts can still play a crucial role in addressing the remaining 20% of security challenges that developers may not be able to handle on their own.
Nicholas Muy: What strategies can organizations adopt to integrate security seamlessly into their development processes, especially for those that may not have access to a dedicated security team? How can DevSecOps and the security champion model be effectively implemented to address the shortage of security professionals and empower development teams to take on security responsibilities?
Farshad Abasi: The aim is to make security an enabler rather than a blocker, especially considering the shortage of security professionals. The concept of DevSecOps is often misunderstood. DevSecOps is meant to be a cultural transformation that addresses the scarcity of security experts. It's not about hiring a specific DevSecOps position; it's about embedding security practices within your existing DevOps teams.
The idea is to enable your DevOps teams to transition into DevSecOps teams by focusing on people, processes, and technology, particularly with an emphasis on enablement. Instead of trying to hire security professionals for each team, you can appoint security champions within your development teams. These champions may not be security experts, but individuals interested in security. They can allocate a portion of their time to learn about and work on security. In this way, they represent security within their teams.
For larger enterprises, the security champion model can scale effectively. For example, in a scenario with a limited internal AppSec team, you can use a third-party supplier like us to support your security champions. The federated model works well to ensure that security is integrated at every level.
To make this approach effective, it's crucial to empower your development teams. Provide them with the knowledge and tools to perform basic security tasks, such as threat modeling and code analysis. Security activities should be integrated into development lifecycles, whether you're following Waterfall, Agile, or DevOps. For instance, during design phases, conduct security design reviews, and when writing user stories, perform threat modeling. In coding phases, run code analysis. The key is to adapt these activities to your sprint cycles, ensuring they become a habitual part of your development process.
Nicholas Muy: What strategies can small and medium-sized companies adopt to efficiently address application security without the need for full-time AppSec hires? How can DevSecOps and automation play a role in helping these organizations overcome the challenges of hiring and retaining security professionals while effectively addressing security concerns?
Farshad Abasi: One of the most common mistakes in small and medium-sized companies is the tendency to hire full-time application security professionals. However, for many smaller organizations, this approach is often not efficient. Typically, they may not have enough security tasks to keep a full-time AppSec person busy.
In fact, even in larger organizations like HSBC, the assignment of a full-time AppSec person to every development team proved to be impractical. Through experimentation, it was determined that the average development team needs security expertise for about 10% to 20% of their time. This ensures that security tasks are adequately addressed without overwhelming the team.
Hiring full-time AppSec professionals can be challenging, time-consuming, and expensive. Furthermore, such individuals often leave within one to two years due to a lack of peers to collaborate with, leading to a limited career path within the organization.
The recommendation is that, unless your organization is large enough to support a dedicated AppSec team, you should focus on implementing DevSecOps as a cultural transformation. Enable your development teams to build secure software through automation, best practices, and standards. Resources like OWASP's Application Security Verification Standard can guide you on building controls into your applications.
Automation plays a crucial role in this approach, but it's essential to select tools that produce minimal false positives for your tech stack. Benchmark different tools against one another to make an informed choice. Additionally, correlating the results across different security scanners is vital to identify real issues and avoid false positive fatigue. Platforms that aggregate, correlate, and orchestrate the outputs of various scanners can significantly reduce the noise and improve developer satisfaction.
Ultimately, alongside effective tooling, training, and enabling your developers to embed security into their daily practices can address many low-hanging fruit vulnerabilities that commonly appear in application security assessments. Training and enablement can go a long way in eliminating recurrent issues and improving the overall security posture.
Nicholas Muy: How have you seen organizations navigate the world of software security, especially in terms of following best practices like manual reviews, design reviews, threat modeling, and source code analysis? Can you share some stories, either from your own experiences or those of your colleagues, where organizations played 'cyber roulette' with software security and how it either succeeded or went awry?
Farshad Abasi: Certainly, a couple of stories come to mind. In one instance, a well-known corporation in British Columbia had a pentest done by another company. The report revealed three vulnerabilities that, upon closer inspection, turned out to be non-issues. These were basic vulnerabilities on their own and couldn't be exploited to attack the system. However, when I looked at the application myself, I discovered numerous other issues that were not even mentioned in the pentest report. This highlighted the lack of understanding and threat modeling on the part of the testing company, which could have left the client with a false sense of security.
In another case, a prominent financial institution in Canada underwent a pentest by a renowned firm, but the report came back empty after three weeks of testing. The client, suspicious of the results, approached us. When we applied our testing methodology, which included design, threat modeling, and code analysis, we identified over 25 issues, many of which were high and medium risk. This demonstrated a significant gap in the testing conducted by the other vendor, despite their reputation.
I'd like to emphasize the value of threat modeling. Take the Capital One breach, for example. The attacker leveraged two vulnerabilities in succession. First, they exploited an unpatched library, and then they took advantage of weakly configured AWS permissions. On their own, each of these vulnerabilities might not have been considered high risk. However, when combined, they created a threat scenario that allowed the attacker to compromise the system. This highlights the importance of assessing vulnerabilities across application and infrastructure layers and conducting thorough threat modeling to identify potential attack scenarios.
The Marriott and Starwood breach serves as another valuable example. In this case, attackers spent nearly two years conducting reconnaissance to identify weaknesses in the systems. After this extended period, they executed their attack. This underscores the critical importance of logging and monitoring in cybersecurity.
Regrettably, many software teams, following the 80-20 rule, either do not implement logging and monitoring or do so inadequately. Typically, they only save logs to a local file and often overlook their proper configuration. Consider the Marriott Starwood incident; the two-year window for the attackers to explore vulnerabilities was a result of insufficient logging and monitoring.
Effective logging and monitoring are key to identifying suspicious activities early on. For example, failed authorization attempts or access control failures should trigger log events. When someone attempts unauthorized interactions with your application, it is an indicator of potential attacks. Similarly, logging input validation failures is crucial, as it indicates malicious input attempts.
OWASP recommends logging and monitoring four main aspects: authentication success and failure, access control failure, input validation failure, and de-serialization failure. Implementing these four categories and centralizing log data, while correlating it with other infrastructure and environmental events, can provide a comprehensive picture of your system's security status. This proactive approach can help identify threats and vulnerabilities more effectively, preventing potential security breaches. Unfortunately, many software development teams do not fully grasp the significance of logging and monitoring or fail to employ them adequately.
Nicholas Muy: How do you see the challenge of translating application-specific logs into something meaningful for the security team, given that these logs are often highly specific to the applications within a software company? It seems like there's a loop of communication where security teams ask for important logs, but the software teams may not fully understand which logs are crucial. Can you share insights on how to bridge this gap effectively?
Farshad Abasi: The standardization of logging and monitoring practices in software security is indeed a critical topic. As of now, there isn't a universally standardized approach to this, and it often leads to varying practices among different organizations. This lack of standardization can be a challenge for security teams trying to gain insight from the logs.
In this regard, you hit the nail on the head when you mentioned the absence of a standard way of reporting logs. While organizations like OWASP provide valuable recommendations, they don't prescribe a specific format for these logs. The OWASP Application Security Verification Standard (ASVS) offers controls, including logging success and failure of authentication, access control, input validation, and de-serialization. However, it doesn't specify the format in which these logs should be stored.
In practice, most developers tend to log data into text files, syslog, or similar formats. The real challenge arises when it comes to ingesting and normalizing these logs, especially for teams using traditional Security Information and Event Management (SIEM) solutions. With these systems, you often need to manually map the logs to understand what they represent and how to correlate them effectively.
In contrast, some organizations, particularly those with substantial resources, opt for solutions like Splunk, which can automate much of this process by intelligently parsing and relating unstructured log data. However, it's worth noting that such sophisticated solutions come at a significant cost.
For those seeking a practical starting point, I highly recommend exploring the OWASP ASVS gold standard. It provides a comprehensive set of 279 security requirements, but not all of them may be relevant to every application. The ASVS categorizes these requirements into different levels (1, 2, and 3) to help organizations tailor their security controls to their specific needs.
To conclude, implementing standardized logging and monitoring practices in line with recommendations like ASVS can significantly enhance an organization's software security. It's crucial to identify the gaps in your existing practices and work toward aligning them with these standards. As a next step, organizations should focus on logging and monitoring and make sure they are doing it appropriately based on OWASP ASVS guidelines. This approach can go a long way toward strengthening software security practices.
Nicholas Muy: Given the importance of white box testing and the extensive efforts attackers invest in understanding their targets, what are your thoughts on how organizations can strike the right balance between black box and white box testing in their security strategies, especially in the context of today's sophisticated threats?
When it comes to the difference between black box and white box testing, it's crucial to understand that attackers and professional pentesters operate in distinct environments. Attackers, who typically engage in black box testing, have the luxury of time on their side. In cases like the Marriott and Starwood breach, they spent two years in reconnaissance, attempting to identify vulnerabilities. They operate with the information they can obtain without access to source code, design details, or architectural information.
Now, the important distinction arises when organizations decide to simulate these attacks by hiring pentesters. Many clients insist on replicating the black box approach, arguing that if attackers do it this way, pentesters should too. However, there's a significant difference: attackers don't have to worry about time constraints as organizations hiring pentesters do. When organizations opt for black box testing, they effectively need to be prepared to pay for an extended period of testing, possibly years, to match what attackers achieve in their own time.
The alternative approach is white-box testing. When organizations provide source code, design information, and architectural details, the pentesters can work with these assets to evaluate the system. White box testing allows them to be far more efficient. In just a few weeks, they can identify vulnerabilities that an attacker might take years to discover in a black-box scenario.
This is a fundamental distinction. While attackers have unlimited time at their disposal, organizations hiring pentesters need to operate within a fixed timeframe and budget. Therefore, the most cost-effective and productive way to conduct these assessments is by opting for white box testing.
In fact, the Application Security Verification Standard (ASVS) by OWASP highlights this point. While it does provide a black box testing option, it also acknowledges that black box testing becomes less effective within short timeframes. Given that organizations are testing their custom code and applications, it is more pragmatic to open up and provide access to critical information for the testing team. By doing this, the organization ensures that the pentest is both efficient and comprehensive.
The challenge here is that many vendors and clients in the industry may not fully grasp this distinction. Some pentesters may take the IP address from a client, conduct black box testing, and then deliver a report. This situation underscores a significant issue within the industry: a lack of understanding regarding the value and nuances of black box versus white box testing.
Nicholas Muy: How can organizations in the Pacific Northwest region get involved with OWASP and take advantage of the resources and events you mentioned, especially if they are looking to enhance their application security practices?
If you're in the Pacific Northwest, you might be interested in the annual OWASP Application Security Pacific Northwest conference. It's held every June, with locations changing yearly. In addition to the conference, there are monthly meetups in various cities with valuable discussions and presentations on application security.
For those looking to start with threat modeling, OWASP provides a great guide and a host of useful, free tools. The OWASP Security Knowledge Framework is a project that helps developers learn application security through modules demonstrating code examples and guides. You'll also find many open-source scanners that can be integrated into your CI/CD pipeline. For Java users, FindSecBugs is a solid choice. Semgrep, both the community and commercial editions, offers robust SAST capabilities. While SonarQube has a free version, keep in mind that its security checks are in the paid developer version.
Open-source tools are an excellent starting point, even though they may generate some false positives. Consider using correlation, aggregation, and orchestration platforms like the Eureka platform to make the most of open-source products. These platforms allow you to combine multiple scanners and efficiently correlate results to identify real issues.
Starting with Static Application Security Testing (SAST) and Software Composition Analysis (SCA) in your pipeline is usually recommended. Once you have these foundational pieces in place, you can expand to other tools like Dynamic Application Security Testing (DAST). Additionally, Interactive Application Security Testing (IAST) tools, such as Contrast, provide an inside view of your applications during QA testing and can significantly reduce false positives.
In summary, you can begin by incorporating SAST and SCA in your pipeline and then expand to other security testing tools like DAST and IAST, depending on your needs and resources.
Nicholas Muy: Well, it's clear that engaging with the cybersecurity community and tapping into valuable resources is essential for both personal and professional growth in the field of security. Farshad has shared an extensive list of resources and emphasized the importance of networking and learning from peers. So, listeners, whether you're looking to enhance your knowledge or strengthen your organization's security practices, remember that the cybersecurity community is a valuable source of support and expertise.
Ready to see what security-first GRC really looks like?
Ready to see what security-first GRC really looks like?
Ready to see what security-first GRC really looks like?
See what a real security- first GRC platform looks like
Ready to see what security-first GRC really looks like?
Focus on the traveler experience. We’ll handle the regulations.
Get Scrut. Achieve and maintain compliance without the busywork.
Choose risk-first compliance that’s always on, built for you, and never in your way.
Ready to see what security-first GRC
One platform, every framework. No more duplicate work.
You can’t manage user access if you’re always playing catch-up.
Explore the future of enterprise GRC
Tired of chasing vendors for risk assessments?
Join the thousands of companies automating their compliance with Scrut.
The right partner makes all the difference. Let’s grow together.
Make your business easy to trust, put security transparency front and center.
Risk-first security starts with risk-first visibility.
Secure your team from the inside out.
Don't settle for slow, expensive compliance. Get Scrut instead.
Risk-first compliance for forward-thinking teams.
Audits without the back-and-forth. Just seamless collaboration.
Scale fast. Stay compliant. Automate the rest.
Compliance? Done and dusted, in half the time.
Get ahead of GDPR compliance before it becomes a problem.
Outgrowing table-stakes compliance? Create custom frameworks with ease.
Navigate SOC 2 compliance, minus the stress.
PCI DSS compliance, minus the panic.
Take the wheel of your HIPAA certification journey today.
We’ve got what you need to fast-track your ISO 27001 certification.
Make your NIST AI RMF journey as smooth as possible.
Your GRC team, multiplied and AI-backed.
Modern compliance for the evolving education landscape.
Ready to simplify healthcare compliance?
Don’t let compliance turn into a bottleneck in your SaaS growth.
Find the right compliance frameworks for your business in minutes
Ready to see what security-first GRC really looks like?
Real-time visibility into every asset
Ready to simplify fintech compliance?
The Scrut Platform helps you move fast, stay compliant, and build securely from the start.
Scrut helps you set up a security program that scales with your business and stands up to audits. Without last-minute chaos.
Scrut helps you streamline audits, close deals faster, and stay ahead of risk without slowing down your team. Because trust shouldn’t take months to earn.
Scrut helps you set up a security program that scales with your business and stands up to audits. Without last-minute chaos.
Tag, classify, and monitor assets in real time—without the manual overhead.
Whether you're entering new markets or launching new products, Scrut helps you stay compliant without slowing down.
Scrut pulls compliance data straight from the tools you already use—so you don’t have to dig for evidence, chase approvals, or manually track controls.
Less manual work, more customizability. The Scrut Platform gives you everything you need to align your compliance to your business’s priorities.
With Scrut, you’re not just adding a tool to your offering—you’re adding a competitive edge. Join our Partner Network and help your clients streamline their GRC program.
Gaining trust is your first step to growing and cracking better deals. The Scrut Platform comes pre-built with all the tools you need to showcase a firm security posture and build confidence.
Don’t settle for rigid systems—Scrut ensures your risk management strategy is as flexible as your business needs.
Start building a security-first culture. Save your operations from improper training and a lack of compliance awareness.
Scrut fast-tracks compliance so you can focus on scaling, not scrambling. Automate compliance tasks and accelerate enterprise deals—without the grind.
Automate assessments, track compliance, and get full visibility into third-party risk—all in one place.
Scrut automates compliance tasks, supports proactive risk management, and saves you time, so you can focus on growing your business. Start building trust with customers and scaling confidently.
Leave legacy GRC behind. Meet the AI-powered platform built for teams managing risk and compliance in real time.
Give auditors direct access, keep track of every request, and manage audits effortlessly—all in one place.
Scrut ensures access permissions are correct, up-to-date, and fully compliant.
Whether you need fast results or a fully tailored program mapped to your risks and needs, Scrut delivers exactly what you need, when you need it. Ready to start?
Scrut unifies compliance across all your frameworks, so you can stop juggling systems and start scaling securely.
Manually managing your compliance processes and audits can get inefficient and overwhelming. Scrut automates these outdated, manual processes and eliminates your last-minute worries.
Access automated compliance, real-time risk tracking, and expert-backed support—all in one platform. Get started with Scrut!
Less manual work, more customizability. The Scrut Platform gives you everything you need to align your compliance to your business’s priorities.
The Scrut Platform helps you move fast, stay compliant, and build securely from the start.
Earn trust and back it up with solid evidence. Scrut takes you through the SOC 2 compliance journey step-by-step, navigating every complexity you face.
Manage your PCI DSS compliance with real-time monitoring and effortless automation. Get started with Scrut today!
Securing your PHI shouldn’t be a constant hassle. Scrut automates your workflows—from risk assessments to monitoring—so you can put your compliance worries on the back burner.
Automate security controls, simplify audits, and keep your ISMS aligned with the latest standards. Get started with Scrut!
Tackle potential AI risks with NIST AI RMF-compliant controls and get expert support every step of the way.
Offload the grunt compliance work to us. Execute manual, draining GRC tasks with the reliable AI-powered Scrut Teammates without switching contexts or bottlenecks.
Whether you're managing student data, partnering with educational institute, or expanding to new geographies—Scrut gives you the tools to stay compliant, manage risk, and build trust at every step.
Scaling healthcare doesn’t have to come at the cost of security. Scrut keeps your organization compliant, audit-ready, and protected—no matter how fast you grow.
Scrut automates the hard parts of compliance and security so you can move fast and stay ahead of risks from day one.
The Scrut Platform helps you move fast, stay compliant, and build securely from the start.
Growth in fintech comes with heavy scrutiny. Scrut helps you stay compliant, audit-ready, and secure—without slowing down your momentum.



