SEC.co Podcast

Eric Lamanna

A podcast about latest trends, techniques and learnings in cybersecurity and cyberdefense.

  1. 1d ago

    Hardware Root of Trust: Beyond the TPM Hype

    Trusted Platform Modules have become shorthand for "secure hardware," but that framing collapses a complex, layered architecture into a single chip — and leaves defenders with a dangerously incomplete picture. This episode of Cybersecurity draws on the in-depth analysis of hardware root-of-trust architecture to explain what genuine trust chains look like, where they break down, and which technologies belong in a mature security stack alongside — or instead of — a TPM. Here's what the episode covers: What "root of trust" really means: Every secure system needs an unconditional anchor — one piece of code or circuitry that everything else chains back to. Without a solid anchor, layered security measures are largely cosmetic.Why the TPM became a marketing phenomenon: Microsoft's Windows 11 TPM 2.0 requirement turned an obscure microcontroller into a headline feature, but the resulting "TPM or nothing" narrative oversimplifies what the chip actually does — and doesn't — protect.Genuine TPM strengths and structural limits: Device identity, sealed storage, and measured boot via Platform Configuration Registers (PCRs) are real capabilities — but the TPM rarely controls power rails or debug ports, and the CPU's Boot ROM fires before the TPM even wakes up, leaving an earlier attack surface exposed.The broader hardware trust ecosystem: DICE (Device Identifier Composition Engine) for constrained IoT, Physically Unclonable Functions (PUFs) and secure elements for key isolation, SoC-integrated enclaves (Apple Secure Enclave, Google Titan, ARM TrustZone), and BMC-based trust chains for data-center servers each solve different parts of the same problem.Pitfalls that never appear on a datasheet: Leaked test keys in manufacturing pipelines, reused root keys across entire product lines, forgotten JTAG/UART debug interfaces left open at ship time, and supply-chain attacks — including the 2017 Infineon RSA key-generation flaw — show how trust chains collapse at the seams rather than at the headline feature.Practical steps for defenders right now: Start with a written threat model; demand supply-chain transparency from silicon vendors; feed PCR values into your SIEM so a TPM that's never polled isn't just idle silicon; enforce firmware rollback protection with monotonic counters; and evaluate whether DICE or a secure element delivers higher assurance than a full TPM stack for your specific deployment.The episode closes with a look at where the industry is heading — quantum-resistant firmware signing, CXL Externalized Integrity, and ARM's Platform Security Architecture (PSA) — and why modular, composable trust designs will matter more than any single chip as those transitions unfold. For more on the hardware fingerprinting side of device identity, check out the episode Hardware Fingerprinting: The Promise and the Pitfalls of Device Identity. SEC

  2. 2d ago

    Hardware Fingerprinting: The Promise and the Pitfalls of Device Identity

    Device identity is one of the trickiest problems in enterprise security. Certificates can be cloned, agent GUIDs can be spoofed, and a rogue machine that looks exactly like a trusted endpoint can slip past even a well-tuned Zero-Trust policy. This episode of Cybersecurity examines hardware fingerprinting — a technique that anchors device identity in silicon-level attributes rather than software — drawing on this deep-dive on hardware fingerprinting for endpoint integrity. The discussion covers both the genuine promise of the approach and the operational, technical, and legal pitfalls that can trip up even experienced security teams. Here's what the episode covers: How hardware fingerprinting works: CPUs, TPM Endorsement Keys, NIC MAC addresses, SSD serial numbers, and sensor calibration data are aggregated into a canonical hash that uniquely identifies a physical device at enrollment — and is checked on every subsequent access attempt.Why it's gaining traction: Unlike software identifiers, hardware attributes are harder to clone or strip out, and once a device is enrolled the check runs invisibly — reducing authentication friction for large remote workforces without sacrificing a meaningful security signal.Beyond authentication: Pairing fingerprinting with endpoint posture services enables near-real-time policy actions — quarantine VLANs, SaaS access blocks, license enforcement, and automated investigation triggers — and fits naturally into a continuous-verification Zero-Trust architecture.Stability and false-positive risks: Hardware repairs, firmware updates, motherboard swaps, virtual machine obfuscation, and rare manufacturing duplicates can all cause legitimate devices to fail fingerprint checks, driving help-desk load and pressure to create policy exceptions.Privacy and legal exposure: Hardware identifiers can constitute personal data under GDPR, CCPA, and Brazil's LGPD; storing raw fingerprints without proper hashing, consent flows, or retention limits may already put an organization out of compliance.Making it work in practice: The episode outlines a layered strategy — salted hashing before storage, zero-touch re-enrollment workflows, firmware integrity validation via Secure Boot and TPMs, behavioral analytics as a cross-check, and thorough lab testing of edge cases before any broad rollout.The core takeaway is that hardware fingerprinting is a valuable telemetry source, not a trust anchor on its own. Organizations that treat it as one layer in a broader stack — alongside EDR, behavioral analytics, and strong user authentication — while proactively managing privacy obligations and re-enrollment paths, stand to gain a meaningful control without the operational drag that derails poorly planned deployments. More from the show: listen to Hardware-Backed Key Storage: When and Why It Matters for a related look at how hardware security primitives underpin modern key management. SEC

  3. 3d ago

    Hardware-Backed Key Storage: When and Why It Matters

    Encryption is only as strong as the protection around the keys that power it. This episode of Cybersecurity examines a control that security teams can no longer afford to overlook: hardware-backed key storage. Drawing on this in-depth article on hardware-backed key storage and why it matters, the episode walks through the core technologies, the real-world gaps in software-only approaches, and the practical steps organizations can take to move critical secrets into tamper-resistant silicon. Here's what the episode covers: What hardware-backed key storage actually means — how TPMs, HSMs, secure enclaves, and embedded secure elements each keep cryptographic keys from ever leaving hardware in plaintext, and how they differ in performance, form factor, and price point.Why software-only storage keeps failing — from memory scraping and disk imaging to supply-chain insertions in CI/CD pipelines, the wide attack surface that opens up when keys live in file systems, environment variables, or Kubernetes secrets.Regulated industries facing hard requirements — how PCI-DSS, HIPAA, FIPS 140-2/140-3, and eIDAS frameworks are pushing auditors to treat software-only key protection as an exception rather than the norm, making hardware the compliance path of least resistance.Cloud, DevOps, and supply-chain risk — why build servers and CI runners are prime targets, and how pinning code-signing keys to HSMs ensures no engineer or compromised script can ever export private key material.Zero-trust and remote workforce scenarios — how TPM-backed certificates let conditional access systems verify machine health before granting entry, keeping VPN and disk-encryption keys safe even when a device's OS is partially compromised.A practical path to adoption — starting with a key inventory, prioritizing high-impact secrets, automating provisioning, enforcing quorum approvals, and planning for key lifecycle events before a crisis forces the issue.The episode also addresses how to evaluate the right solution — weighing certification level (FIPS 140-2/140-3 Level 2 or 3), throughput requirements, integration ecosystem (PKCS #11, JCE, KMIP), and whether cloud-based pay-as-you-go HSM offerings make more sense than dedicated on-premises hardware. The closing message is direct: hardware-backed key storage isn't a silver bullet, but it eliminates one of the most consistently exploited vectors in an attacker's playbook — and the time to evaluate it is before keys walk out the door. For more on API-layer attack techniques from the same show, check out GraphQL Abuse: Introspection, Batching, and Over-Fetching Attacks Explained. SEC

  4. 3d ago

    GraphQL Abuse: Introspection, Batching, and Over-Fetching Attacks Explained

    GraphQL trades the sprawl of REST APIs for a single, powerful endpoint — but that concentration of access is exactly what makes it a compelling target. This episode of Cybersecurity examines three increasingly common GraphQL attack patterns in depth, drawing on this detailed technical breakdown of GraphQL abuse, detection, and prevention. Whether your team ships GraphQL APIs or defends them, the mechanics covered here are directly applicable to production environments today. The episode walks through each abuse pattern — how it works, what it looks like to an attacker, and what defenders can do about it — before zooming out to cover cross-cutting security practices that apply across all three. Here's what's covered: Introspection leaks: How a single well-formed introspection query hands attackers a complete map of your API schema — every type, field, argument, and suggestive field name — and why verbose schema descriptions make the exposure worse.Disabling introspection safely: Why production APIs should gate introspection behind authentication, strip public descriptions, and reserve full schema access for internal tooling and trusted roles.Batching as a rate-limit bypass: How attackers pack dozens of operations into a single HTTP request to defeat transport-layer rate limiting, amplify brute-force attempts, and disguise scanning campaigns as ordinary traffic.Cost-aware rate limiting: The case for counting operations, field selections, and resolver complexity — not just requests — and setting hard per-request budgets that honest clients rarely hit.Over-fetching as a weapon: How deep, relationship-chaining queries can silently degrade backend performance, fan out across services, and cross authorization boundaries that were never enforced at the field level.Schema hygiene and cultural practices: Why threat-modeling schema additions before they ship, enforcing field-level authorization, and rewarding engineers who prune fields are just as important as technical controls.The episode closes with a call to treat the GraphQL schema as a living security perimeter — logging at the resolver level, building cost-ceiling alerts, and applying the same rigor to new types and mutations that security teams apply to firewall rules. For more from the show on how emerging technologies reshape both attack and defense, check out the episode GPT and Cybersecurity: How LLMs Are Reshaping Attack and Defense. SEC

  5. 4d ago

    GPT and Cybersecurity: How LLMs Are Reshaping Attack and Defense

    Artificial intelligence has arrived in cybersecurity — and it didn't pick a side. This episode of Cybersecurity examines how large language models like GPT are simultaneously becoming one of the most valuable assets in a defender's toolkit and one of the most dangerous weapons in an attacker's arsenal. Grounded in this in-depth look at LLMs in offensive and defensive security, the episode offers a clear-eyed, practical breakdown of where the technology genuinely helps, where it genuinely threatens, and what security teams should do about it today. Here's what the episode covers: Why this moment is different: Unlike past technology waves, LLMs moved from research novelty to enterprise-wide deployment in just a couple of years — giving both defenders and attackers almost no runway to prepare.AI-powered threat detection: LLMs can ingest logs and alerts at machine speed, surface anomalies that would take analysts hours to find manually, and free up skilled practitioners for the judgment-heavy work that machines still can't handle.Operational efficiency gains: Incident reports, policy drafts, threat intelligence summaries, and mitigation plans — tasks that drain high-skill hours — can be delegated to AI assistants, helping especially mid-market teams punch above their weight.The phishing problem, reimagined: AI-generated social engineering is now grammatically flawless, contextually plausible, and personalized at scale, effectively erasing the traditional "bad grammar" tell that employees were trained to spot.Lowered barriers for attackers: Automated vulnerability probing, self-mutating malware, and scalable attack campaigns are all more accessible when AI handles the heavy lifting — driving up attack frequency and variety while defenders remain stretched thin.Four actionable priorities: Integrate AI-assisted detection, modernize phishing-awareness training, layer technical defenses, and commit to continuous learning rather than treating security as a static checklist.The episode's central argument is that LLMs are a force multiplier, not a villain or a savior — and that the outcome depends entirely on preparedness. Organizations that understand the dual nature of this technology and build adaptive strategies around it will be the ones that stay ahead of an accelerating digital arms race. For more on how legacy and overlooked code can introduce serious risk, check out the episode Ghost Dependencies: How Stale Code Can Still Be Malicious. SECCyber Software

  6. 6d ago

    Ghost Dependencies: How Stale Code Can Still Be Malicious

    Every codebase carries passengers: libraries no one remembers adding, transitive dependencies that hitchhiked in years ago, dev tools that quietly slipped into production builds. This episode of Cybersecurity explores why these forgotten packages — ghost dependencies — are far from harmless, drawing on this in-depth article on stale code as a security risk. The uncomfortable truth is that inactivity isn't a security property, and the corners of your dependency tree that nobody watches are exactly the corners attackers study most carefully. The episode covers how ghost dependencies form, how adversaries exploit them, and what a practical, layered defense actually looks like in production environments: What makes a dependency a "ghost" — unpinned relics, transitive passengers, and dev tools that outlived their purpose, united by the fact that no one claims ownership.Inactivity as a false signal of safety — stale packages carry their vulnerabilities indefinitely, with no maintainer watching CVE feeds and no patches on the way.Impersonation and typosquatting risk — dormant packages become furniture that no one scrutinizes, making them ideal targets for near-identical name spoofing that slips past even experienced developers.Hijacked maintainer accounts — abandoned projects tied to expired university or startup email addresses can be silently inherited by anyone who acquires the old domain, granting legitimate-looking publish rights.The version-pinning trap — locking a release in place preserves its vulnerabilities just as firmly as it preserves its behavior, turning a cautious practice into a stationary target.Practical defenses — living dependency inventories, reachability analysis to prioritize blast radius, isolation for packages that can't be replaced, named human ownership per critical dependency, and disciplined lockfile hygiene tied to real patch windows.The episode closes with a clear through-line: silence is not safety, and attackers rely on the assumption that what didn't break yesterday won't break today. Building a well-lit, actively governed dependency graph — combining automated tooling with genuine human accountability — is what keeps ghost dependencies from becoming ghost entry points. If you enjoyed this episode, also check out Flow-Based Detection vs. DPI: Performance vs. Precision for another deep dive into the tradeoffs at the heart of modern security architecture. SEC

  7. Jul 18

    Flow-Based Detection vs. DPI: Performance vs. Precision

    Network security teams face a fundamental trade-off: see everything in granular detail, or maintain the speed and scale needed to protect a modern enterprise. This episode of Cybersecurity tackles that tension head-on, walking through the architectural logic behind flow-based detection and Deep Packet Inspection (DPI) — and why the sharpest security operations centers treat them as complementary tools rather than competing philosophies. The discussion draws on this in-depth comparison of flow-based detection and DPI from the team at SEC. The episode covers the real-world strengths, limitations, and deployment contexts for both approaches, including: How flow-based detection works: Traffic is condensed into compact metadata records — source, destination, port, duration, volume — giving analysts a behavioral map of the entire network without capturing payloads or taxing infrastructure.Where flow monitoring hits its limits: Because flows never inspect packet content, encrypted threats that blend into normal traffic patterns — such as malware beaconing over HTTPS — can evade detection entirely, creating blind spots for low-and-slow or insider threats.What DPI actually delivers: Deep Packet Inspection dissects each packet layer by layer, enabling precise application identification, payload-level signature matching, and forensic-grade evidence — capabilities essential for email gateways, data loss prevention, and incident reconstruction.The real cost of DPI at scale: Full packet inspection on high-throughput links demands significant hardware investment, and decrypting the now-dominant share of encrypted enterprise traffic adds latency, complexity, and compliance exposure under frameworks like GDPR and HIPAA.Environments that favor each approach: Cloud workloads, IoT/OT networks, and distributed branch offices tend to suit flow-based coverage; egress firewalls, cloud interconnects, and active incident response scenarios are where DPI earns its overhead.A practical hybrid architecture: Deploy DPI at high-risk choke points, enable flow collection across all available network infrastructure, and build automated workflows so that flow anomalies trigger targeted DPI investigation — radar for early warning, microscope for confirmation.The episode closes with concrete guidance for architects and security leaders: map your traffic corridors, identify where risk is actually concentrated, and design a detection workflow where lightweight behavioral monitoring and deep content inspection each do what they're genuinely best at. For more on how security decisions at the architecture layer shape overall posture, check out the episode on Feature Flag Security Risks: Kill Switches, Rollouts, and Guardrails. SECCybersoftware.ai

  8. Jul 17

    Feature Flag Security Risks: Kill Switches, Rollouts, and Guardrails

    Feature flags sit quietly inside nearly every modern codebase, giving engineering teams the power to toggle behavior at runtime without touching a deployment pipeline. But that same power introduces layered risks — operational, architectural, and security-related — that most teams don't fully reckon with until something breaks at 3 a.m. This episode of Cybersecurity works through the discipline behind feature flags done right, drawing on this in-depth look at feature flag security risks and best practices to cover what separates a genuine safety mechanism from a false sense of control. The episode covers three interlocking areas — kill-switches, gradual rollouts, and system-wide guardrails — and examines how each layer contributes to (or undermines) engineering resilience and security posture. Here's what's addressed: Kill-switch design under pressure: What makes an emergency flag actually work — narrow blast radius, low-latency config stores, pre-defined ownership, and fast authentication workflows that don't stall in a crisis.Gradual rollout discipline: Why sticky identity-level assignment, mutually exclusive cohorts, and pre-defined stop conditions matter more than arbitrary percentage ladders and optimistic timelines.Flag lifecycle governance: How expiry dates, team ownership, and automated cleanup alerts prevent temporary flags from becoming permanent, unaudited code paths.Access control and the flag control plane: Why flag stores deserve the same security treatment as production credentials — scoped keys, per-environment roles, MFA, and audit logs forwarded to a SIEM.Flags as an attack surface: How a compromised flag credential can shift traffic, degrade service, or open shadow access paths — and what detection controls (change-frequency alerting, circuit breakers, signed client-side payloads) close those gaps.Observability requirements: Why every flagged code path needs event logging tied to traces, and how a live rollout dashboard prevents the most dangerous incident question: "Wait, is the flag even on right now?"The throughline is that feature flags reward operational discipline. The technology itself doesn't make systems safer or riskier — the habits, policies, and controls wrapped around it do. Practiced kill-switch drills, evidence-driven rollouts, and a hardened flag control plane are what separate teams that ship confidently from teams that accumulate hidden risk with every release. For more on how infrastructure decisions intersect with security, check out the episode on Encrypted DNS in Enterprises: Balancing Privacy, Control, and Visibility. SECCybersoftware.ai

See All (51)

About

A podcast about latest trends, techniques and learnings in cybersecurity and cyberdefense.

Information

  • Creator
    Eric Lamanna
  • Years Active
    2026
  • Episodes
    51
  • Rating
    Clean
  • Copyright
    © 2026 SEC.co
  • Show Website
    SEC.co Podcast