Security Confidential S6 E5 Nat Shere

Manoj Tandon:
Hello everyone, welcome to another episode of Dark Rhino Security’s Security Confidential. I’m your host, Manoj Tandon, and today we have a very special guest, Nat Schere. Nat brings a tremendous amount of experience in the cybersecurity industry. He is a cybersecurity consultant specializing in ethical hacking and secure coding, has worked as a product security engineer, and has extensive experience helping developers integrate security into the products they bring to market. He holds a Master’s in Computer Security and has taught undergraduate courses in both Mathematics and Computer Science. Nat, welcome to the show. Thank you so much for being here.

Nat Schere:
Thanks for having me.

Manoj Tandon:
Nat, there’s so much I want to ask you, and I’m not sure we’ll get to everything, but let’s start with one of the fundamentals of cybersecurity—penetration testing. As a cybersecurity company, we get a lot of requests for it, and in many cases, it’s driven by compliance requirements. Organizations are often required to do it annually, but what we see is that many companies are just checking the box. How can organizations go beyond that and actually use penetration testing to reduce their attack surface and overall risk?

Nat Schere:
When organizations are just checking the box, they typically hire a penetration testing firm, receive the report, maybe skim the executive summary, and then move on. That’s not where the value comes from. You really need to look at it from two perspectives: what’s happening during the engagement and what you do after with the report.

What’s often overlooked is the active testing phase. That’s real attack traffic hitting your environment. You should be monitoring logs, reviewing IDS or IPS alerts, and seeing whether your security tools and teams—especially your SOC—are detecting that activity. Then, after the engagement, you correlate those findings with what was observed. For example, if I report a SQL injection vulnerability and your SOC didn’t detect it, that’s a major gap in your monitoring capabilities—not just a vulnerability to fix, but a detection problem to address.

Manoj Tandon:
That’s a great point. One thing we see, especially in small and mid-sized businesses, is cost constraints. They still have regulatory requirements, but limited budgets often lead them to reduce the scope of testing. They might only test a range of IPs and skip application testing or social engineering because those require more time and cost. What would you say to organizations that intentionally limit scope like that?

Nat Schere:
It often comes down to budget, and sometimes limiting scope is unavoidable. But if that’s the case, you need to be strategic. The worst thing you can do is spend money just to check a box. If you’re limiting scope, focus on what matters most—your highest-risk assets. Identify the systems that hold sensitive data, like financial information or PII, and prioritize testing those.

Do a proper risk analysis and make sure you’re getting real value out of the engagement. Then, over time, you can expand testing to other areas or implement additional controls where full testing isn’t feasible. It’s about maximizing impact with the resources you have.

Manoj Tandon:
Do you help clients with that risk analysis? Because that’s an area where a lot of organizations struggle.

Nat Schere:
Absolutely. Especially when budget is a constraint, I want to make sure the engagement is meaningful. It’s not valuable for me to do a test that just results in a report that sits unread, and it’s certainly not valuable for the client to pay for that. So yes, I work with clients to identify what’s most important and focus efforts there.

Manoj Tandon:
Are there any practical resources—guides, tools, or frameworks—that organizations can use to conduct even a basic risk analysis before planning a penetration test?

Nat Schere:
There are definitely resources out there. We have some articles on our website, and I also share content on LinkedIn. I’m always happy to point people in the right direction or answer questions if they’re trying to figure out where to start.

Manoj Tandon:
That would be great—if you can share those, we’ll include them in the show notes. From what we’ve seen, there’s a lot of inconsistency in how organizations approach risk. Some are very thorough, while others are more reactive.

Let me ask you this—SQL injection has been around for a long time. You would think developers would have addressed it by now. Are you still seeing it in the wild?

Nat Schere:
You would think it would be gone, but while it has improved, I still see it fairly often. It’s not as prevalent as it used to be, but it’s definitely not eliminated.

Manoj Tandon:
That’s interesting. I remember a case in the UK where someone put a SQL injection query on a license plate, and it actually triggered a system in traffic cameras. It just shows how creative attackers can be.

Let’s shift gears a bit and talk about third-party risk. How would you define it?

Nat Schere:
Third-party risk is essentially anything outside of your direct control. That includes your supply chain, vendors, contractors, third-party software, and even services like penetration testers. Anyone who has access to your systems, data, or environment introduces some level of risk.

Manoj Tandon:
That’s an important point. It’s not just an insurance concept—it’s a very real operational concern. When we look at application development through that lens, especially with open-source code and frameworks, how should organizations approach security?

Nat Schere:
The first step is simple but often overlooked—read the documentation. Most frameworks provide security guidelines and best practices. Understanding how the software is intended to be used securely is critical.

The second step is architectural. You need to design applications so that dependencies can be updated easily. A common issue is tightly coupled dependencies that make updates difficult. When a vulnerability is discovered in a library, developers might delay patching because updating breaks other parts of the system. That’s a design problem.

Manoj Tandon:
Why do you think that problem persists?

Nat Schere:
It comes down to speed and incentives. Developers are under pressure to deliver products quickly, and shortcuts—like hard-coding or tightly coupling dependencies—help them move faster. But those shortcuts create long-term security and maintenance challenges.

It takes leadership and a strong security culture to say, “We’re going to do this right from the beginning.” Security can’t be an afterthought.

Manoj Tandon:
That ties into another common misconception—that cloud providers like Amazon, Google, or Microsoft handle all security. We hear that all the time.

Nat Schere:
That’s a major misunderstanding. Cloud providers follow a shared responsibility model. They handle the infrastructure, but you are responsible for your applications, configurations, and data. If your application has a vulnerability, that’s on you—not the cloud provider.

We’ve seen countless examples of misconfigured storage, like publicly exposed S3 buckets. Even with all the warnings and safeguards in place, these issues still happen because people don’t fully understand their responsibilities.

Manoj Tandon:
That leads into communication. There seems to be a gap between security professionals and executives. Do you think that’s part of the problem?

Nat Schere:
Yes, but it’s not just about being more forceful. In fact, being overly forceful can backfire. The real issue is communication. Security professionals need to translate technical risks into business terms.

Executives think in terms of financial impact and business risk. If you say, “We might get hacked,” that’s not enough. You need to explain what that means in terms of cost, downtime, reputation, and revenue. That’s how you get buy-in.

Manoj Tandon:
That’s exactly right. So how do we bridge that gap?

Nat Schere:
There’s no simple solution—it comes down to improving communication. One approach I’ve been exploring is framing security as a business advantage, not just risk mitigation. More consumers are choosing products based on privacy and security. Companies that can demonstrate strong security practices can use that as a differentiator.

Instead of just saying, “We avoid breaches,” you can say, “We are a secure platform, and that’s why you should trust us.” That can actually drive revenue.

Manoj Tandon:
That’s a powerful shift—positioning cybersecurity as a revenue enabler rather than just a cost center.

Let’s talk about MFA. It’s widely recommended, but we’re still seeing issues. What should organizations know?

Nat Schere:
First, MFA is always better than not having it. But it’s not foolproof. It needs to be configured correctly. Attackers are increasingly targeting MFA, often through social engineering—like tricking users into sharing codes.

There are also implementation issues, like weak configurations or improper integration. In some cases, MFA can even be bypassed if it’s not set up correctly. So it’s important to follow best practices and understand the limitations.

Manoj Tandon:
What about mobile devices? They’re everywhere and represent a huge attack surface. How should organizations approach that?

Nat Schere:
Mobile devices are challenging because they’re both personal and professional tools. One approach is segmentation—allowing devices to access the internet but not internal networks. Another is using mobile device management solutions to monitor and control usage.

But again, there are trade-offs. MDM solutions can raise privacy concerns, especially for personal devices. That’s where communication comes in—explaining the benefits and ensuring employees understand the purpose.

Manoj Tandon:
That ties back to culture. If security is seen as a barrier, people will work around it.

Nat Schere:
Exactly. Security teams need to position themselves as enablers, not blockers. One thing I strongly recommend is having a designated security contact—someone employees can go to directly with questions. That human connection makes a huge difference.

When security feels approachable, people are more likely to engage with it rather than bypass it.

Manoj Tandon:
That’s fantastic advice. It could go a long way in reducing shadow IT.

Before we wrap up, from your experience, what are some common failure points you see with SOC teams?

Nat Schere:
Two big ones: gaps in coverage and alert fatigue. Sometimes SOC teams simply don’t detect certain attack patterns. Other times, they’re overwhelmed with alerts, and important signals get buried. By the time they investigate, the attacker may have already achieved their objective.

Proper tuning, prioritization, and configuration of tools are critical to addressing those issues.

Manoj Tandon:
That’s very insightful. As we wrap up, is there anything you’d like to share with our audience?

Nat Schere:
I’m currently working on a book, though that’s still a long-term project. In the near term, I’ll be speaking at Nebraska Code, a developer conference, where I’ll be presenting on security topics—especially around framing security as something to promote, not just something to manage.

We also have resources on our blog that expand on these ideas.

Manoj Tandon:
That’s great. We’ll make sure to include those links. Nat, thank you again for joining us. This has been a fantastic conversation, and we’d love to have you back in the future.

Nat Schere:
Thank you so much. I appreciate it.