Security

A Practical Interlude in My Cybersecurity AI Series I’m excited to share my new Censys MCP tools module that demonstrates how AI capabilities can enhance security workflows when guided by domain expertise. My previous articles here and here explored how the integration of human insight and AI will shape security’s future, introducing the hacker-strategist archetype and examining prompt engineering’s strategic dimensions. Today, I’m offering a practical example connecting those concepts through a project that brings natural language interfaces to OSINT workflows. ...

In our previous exploration of cybersecurity’s AI-driven evolution, we examined how automation is reshaping our field and giving rise to a new type of professional—the hacker-strategist. Now I want to delve deeper into perhaps the most critical skill this hybrid role demands: prompt engineering. The Strategic Dimension of Prompt Engineering Prompt engineering in cybersecurity transcends the technical mechanics of crafting effective AI queries. It represents a fundamental shift in how security expertise is applied. As routine analyses become increasingly automated, the most valuable security professionals will be those who can leverage AI capabilities effectively—knowing when to use one-shot prompts, when to build multi-step workflows, and when to deploy more complex agentic solutions—all while maintaining the creative, boundary-testing mindset that has always characterized our field. ...

After decades in cybersecurity, patterns emerge. The security landscape has always valued deeply technical experts, and this foundation remains vital. But as AI transforms our field, I’m seeing the emergence of a pivotal role at the intersection of technical depth and strategic thinking—what I call the “hacker-strategist.” This isn’t about creating a new title. Many security professionals already embody aspects of this archetype (hi!). Rather, it’s about recognizing which skills will become essential as AI reshapes cybersecurity. And, silently, those that will be obsolete. But don’t fret, there’s a way forward if you’re willing and able. ...

The security industry’s standard response to SSL/TLS protocol vulnerabilities drives organizations into urgent version upgrades, suggesting severe and immediate risk. However, the vast majority of these vulnerabilities share an major prerequisite: attackers must first achieve specific network positions. When attackers gain such positions, they typically have access to simpler and more reliable attack methods. Additionally, by analyzing technical requirements, modern mitigations, and practical attack scenarios across multiple protocol versions (SSL 3.0 through TLS 1.1), we uncover a significant disconnect between these protocol vulnerabilities, their practical risk, and how organizations seemingly over-respond. ...

This technical analysis serves as a companion piece to our main article “Is TLS Your Biggest Problem?” While the main article examines the broader implications of TLS protocol security, these appendices provide exhaustive technical details across four critical areas: network position prerequisites, browser/library implementation timelines, network position analysis, and comprehensive CVE analysis. For security practitioners and technical teams, these appendices offer the detailed technical foundation underlying the main article’s conclusions. By examining the specific technical requirements, historical implementation details, and practical attack considerations, we demonstrate why theoretical vulnerabilities often face significant practical exploitation barriers. ...

I’ve come to recognize two distinct mindsets in security: those grounded in technical reality, and those I call the “boogeyman crew.” The latter operates on fear rather than facts, treating every scanner-flagged “CRITICAL!” finding as an equally urgent disaster. Their world is populated by various specters: the compliance boogeyman who’ll condemn them for not addressing every high-severity CVE regardless of context, the dreaded auditor who’ll condemn them for not following frameworks to the letter and, of course, the truly bad actors lying in wait. ...

Traditional vulnerability scanning has been a cornerstone of enterprise security programs for decades. However, some fundamental aspects of how these tools operate - and how quickly vulnerabilities are exploited in the wild - suggest we might need to reconsider this approach. This analysis explores why scanning might be problematic as a primary security measure, particularly for Internet-facing systems, and considers what alternatives might look like. The Empirical Case Against Scanning I’d like to explore some observations about how traditional network and web vulnerability scanners work and why their core premises might be problematic, particularly when assessing Internet-facing systems. While this analysis focuses primarily on Internet-exposed hosts, many of these fundamental limitations apply equally to internal systems that aren’t directly accessible from the Internet. ...

Built a tool called censyspy that simplifies FQDN discovery via Censys. While you can absolutely do all of this with the Censys CLI and their query syntax (which isn’t particularly complex), this wrapper makes it a bit more straightforward if you’re specifically hunting for FQDNs. Since Censys has such a massive certificate dataset, queries can take a few minutes to complete - the tool defaults to a 5-minute timeout which should be enough for most cases. ...