[{"content":"I\u0026rsquo;m a cybersecurity leader based in Japan — a Senior Manager in Cyber \u0026amp; Information Security at a Big 4 global consulting firm and an authorized ISC2 instructor teaching CISSP, CCSP, and AI strategy.\nMy background spans offensive security, red teaming, penetration testing, and operational technology (OT) security, anchored by deep expertise in security architecture, incident response advisory, and cyber project management. With a current focus on how AI is reshaping both attack and defense, I bridge the gap between tactical execution and strategic resilience.\nI also build open-source security tooling and write about what I learn. This site is where I share tools, writeups, and analysis.\nWhat I focus on # Offensive AI security — how threat actors and red teams weaponise AI Red teaming \u0026amp; penetration testing — application and infrastructure testing Security architecture \u0026amp; incident response — designing resilient systems and guiding organizations through critical security events Operational Technology (OT) security — securing industrial control systems (ICS/SCADA) and critical infrastructure Security leadership \u0026amp; project management — strategy, governance, and driving complex international delivery programs Education — developing the next generation of cybersecurity leaders ","date":"21 October 2026","externalUrl":null,"permalink":"/","section":"Barry O'Callaghan","summary":"I’m a cybersecurity leader based in Japan — a Senior Manager in Cyber \u0026 Information Security at a Big 4 global consulting firm and an authorized ISC2 instructor teaching CISSP, CCSP, and AI strategy.\n","title":"Barry O'Callaghan","type":"page"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/posts/","section":"Blog","summary":"","title":"Blog","type":"posts"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/categories/cryptography/","section":"Categories","summary":"","title":"Cryptography","type":"categories"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/cryptography/","section":"Tags","summary":"","title":"Cryptography","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/defense/","section":"Tags","summary":"","title":"Defense","type":"tags"},{"content":"The first thing you learn in any migration project is that you can\u0026rsquo;t secure what you can\u0026rsquo;t see. Quantum readiness is no different. Before anyone upgrades an algorithm or swaps a certificate, the organisation has to answer a much simpler question: where is the cryptography actually sitting?\nThat question is harder than it sounds. Encryption has crept into nearly every layer of modern infrastructure. It lives in the obvious places — web servers, VPN concentrators, certificate stores — and in plenty of less obvious ones: embedded controllers, firmware images, backup tapes, configuration files, third-party SDKs. Some of it was deployed deliberately, with documentation and ownership. Some of it arrived bundled inside a vendor appliance five years ago and nobody has looked at it since.\nAll of it counts. A quantum computer won\u0026rsquo;t care whether the RSA key it breaks was part of a carefully managed PKI or a forgotten TLS certificate on a development server. If the key protects data that still matters, the exposure is real.\nThis chapter is about building the map. Discovery first, then classification, then the structures — like the Cryptographic Bill of Materials — that turn a one-off exercise into something durable.\nThree questions every inventory has to answer # A cryptographic inventory isn\u0026rsquo;t a list of certificates. It\u0026rsquo;s the answer to three questions, asked repeatedly across every system you own:\nWhat crypto is in use? Not just the protocols, but the specific algorithms, key sizes, and configurations.\nWhere does it sit? Which servers, which appliances, which codebases, which third-party services.\nWho or what depends on it? What breaks if it changes, what data does it protect, and how long must that protection last.\nStart with the surface area most likely to matter. TLS endpoints on public and internal services. VPN tunnels — site-to-site and client access. Digital signatures that verify firmware, packages, and application code. API certificates. Encrypted storage volumes. Hardcoded keys in IoT firmware.\nThat list alone covers most of what runs in a typical enterprise. Each entry on it probably relies on RSA or ECC in some form, and both of those are on the clock.\nWhat you\u0026rsquo;re actually looking for # Go beyond the obvious. A cryptographic inventory that only counts TLS certificates misses the bulk of the problem.\nThe checklist # Scan for all of this:\nTransport encryption. TLS on web servers, APIs, internal services, mail servers, and database connections. Don\u0026rsquo;t assume internal traffic is fine just because it\u0026rsquo;s behind a firewall. If it uses RSA or ECDH for key exchange, it\u0026rsquo;s in scope. VPNs. IPsec and WireGuard tunnels, SSL VPN appliances, SD-WAN overlays. Most established VPN architectures lean heavily on Diffie-Hellman or elliptic curve key agreement. Certificates. Not just the ones on web servers. Code-signing certificates, email (S/MIME), client authentication, mutual TLS, and internal PKI infrastructure. Expiry isn\u0026rsquo;t the only concern — the algorithm underneath matters. Firmware and device signatures. Anything that boots from signed images. Anything that validates a package before installation. If the signing key is RSA or ECDSA, a future adversary can forge valid signatures. Data at rest. Full-disk encryption, database column encryption, backup encryption, encrypted archives. The algorithms used to wrap the data keys are almost always asymmetric. Embedded and OT. Industrial controllers, building management systems, medical devices. These often have cryptographic functions baked in at the factory with no update path. For every item you find, document more than the algorithm. Capture its purpose (what function does it serve?), its lifespan (when was it deployed, when does it expire or get replaced?), and its exposure (is it reachable from the internet, a partner network, or only locally?).\nWhere to begin # Don\u0026rsquo;t try to inventory everything at once. Start with the protocols you already know about. TLS and VPNs are universal — every organisation uses them, and they\u0026rsquo;re the easiest to scan. From there, expand outward: certificates, code signing, firmware verification, storage encryption, and finally the embedded and operational technology that requires specialised tooling.\nWhat belongs in each entry # For each cryptographic artifact, record the algorithm family (RSA, ECDSA, AES, etc.), the key length or curve, the cipher mode where applicable, and the protocol version. Note whether the implementation supports algorithm replacement without re-architecting the application — what we\u0026rsquo;ll call crypto-agility later on.\nThen connect the artifact to the data it protects. How sensitive is that data, and how long does its confidentiality need to hold? A TLS certificate securing session data with a one-hour lifespan is a fundamentally different priority from an encryption key wrapping medical records with a statutory thirty-year retention period. Tying technical findings to data classification is what turns the inventory from a compliance artefact into a decision-making tool.\nTooling and automation # No one does this by hand at scale. The tooling landscape falls into several categories.\nDiscovery scanners can crawl networks, interrogate TLS endpoints, enumerate certificates from public and internal sources, and produce structured output. They handle the broad sweep — flagging weak configurations, expired certificates, and compliance gaps. Many can now export a Cryptographic Bill of Materials directly.\nQuantum readiness platforms go a step further. They correlate discovery data against known quantum-vulnerable algorithms, assign risk scores, and track crypto-agility across the estate. Some include professional services that combine the scan output with maturity assessments and regulatory mapping.\nProtocol-level analyzers are for environments where agents can\u0026rsquo;t run. Embedded systems, industrial controllers, legacy appliances — these need network-based fingerprinting. The tools are more specialised and the coverage is less complete, but they\u0026rsquo;re the only option for devices you can\u0026rsquo;t instrument.\nWhatever you choose, the real value comes from integration. Plug the scanner into your CI/CD pipeline so new deployments get checked the moment they\u0026rsquo;re built. Feed the output into your CMDB or asset management platform so the inventory stays current. Set up alerts for anything that introduces a vulnerable algorithm or an unauthorised certificate.\nThe process, step by step # Whether the scan is automated or manual, the workflow is the same:\nScope it. Pick your starting surface — a business unit, a network segment, a set of critical applications. Don\u0026rsquo;t boil the ocean. Scan it. Run the tools. Get the raw output. Verify it. Talk to the people who own the systems. Review configs, build scripts, and deployment manifests. Scanners produce false positives and gaps; human review closes them. Document it. Normalise everything into a consistent format. Algorithm, key length, mode, version, owner, data classification. Map it. Connect each entry to the asset it protects and the business process it supports. Flag it. RSA and ECC: high priority. AES-128: watch. AES-256 and SHA-3: low risk for now. Store it. Put the inventory somewhere version-controlled and queryable — not a spreadsheet that goes stale the moment it\u0026rsquo;s saved. The Cryptographic Bill of Materials # If an SBOM tells you what software components are in a product, a CBOM tells you what cryptography those components rely on. It\u0026rsquo;s a structured extension of the SBOM standard, designed to capture cryptographic dependencies with the same rigour that SBOMs apply to library versions.\nWhy does this matter? Because most cryptographic risk doesn\u0026rsquo;t come from your own code. It comes from the library you imported, the framework you depended on, or the appliance your vendor shipped. A CBOM makes that inherited risk visible.\nA well-formed CBOM records the algorithm, the implementation, the key length, the purpose (signing, encryption, key exchange), and any known quantum vulnerabilities. It ties each entry to the component that uses it and the supplier who provided it. This turns an abstract concern — \u0026ldquo;we might have RSA somewhere\u0026rdquo; — into something actionable: \u0026ldquo;version 2.3.1 of the authentication library uses RSA-2048 for JWT signing, and the fix is in version 2.4.0.\u0026rdquo;\nBeyond development, CBOMs support procurement. When a vendor claims their product is quantum-ready, a CBOM lets you verify that claim instead of taking it on faith. They also support compliance: auditors increasingly expect evidence that cryptographic risk is being managed systematically, and a maintained CBOM is one of the strongest forms that evidence can take.\nBuilding one # Add cryptographic scanning to your build pipeline. Static analysis can identify calls into crypto libraries even when the configuration is hidden. Extract the metadata: algorithm, library name and version, key parameters, usage pattern. Express it in a standard format. The CycloneDX CBOM extension is the current reference. Commit the result alongside your SBOM in version control. Generate a fresh CBOM with every release so it stays accurate as dependencies change. Review it during security assessments, vendor evaluations, and architecture reviews — not just at audit time. Turning findings into priorities # Discovery produces data. Triage turns it into something you can act on.\nEvery finding should be assessed on three dimensions: the algorithm\u0026rsquo;s vulnerability to quantum attack, the sensitivity of the data it protects, and the difficulty of replacing it.\nRSA and ECC key exchange are immediately vulnerable once a cryptographically relevant quantum computer exists. Flag them as high priority regardless of where they sit. Symmetric algorithms like AES-128 sit in a middle tier — they\u0026rsquo;re not directly broken by quantum algorithms, but the effective key strength is halved, which means an upgrade will be needed eventually. AES-256 and SHA-3-based constructions are fine for now.\nNext, link each finding into your broader operational systems. A vulnerable TLS configuration on an API gateway should create a ticket in your vulnerability management platform. A certificate shared between a cloud frontend and an internal service should appear in both asset records. The inventory only delivers value when it\u0026rsquo;s connected to the systems that drive remediation.\nTo keep the link live:\nTag assets with searchable labels: quantum-vulnerable, crypto-agile, legacy-no-upgrade-path. Wire the scanning tools into CI/CD so new findings surface in real time. Define SLA timelines based on severity and exposure — not everything needs to be fixed this quarter, but the highest-risk items need hard deadlines. Tie CBOM entries to incident response playbooks. If a vulnerability drops in a library you depend on, you should be able to identify every affected system in minutes. What the inventory reveals # A complete inventory does more than list encryption. It answers questions about risk that most organisations have never formally asked.\nWhich data matters most? Walk through your datasets and ask how long each one needs to stay confidential. Transaction logs might have a short shelf life. Intellectual property, legal records, and personal health data might need decades. The data with the longest privacy tail should drive your migration schedule.\nWhich applications handle it? Map the applications that touch your high-value data. How do they encrypt it in transit and at rest? What happens if the trust model breaks — can someone decrypt stored data, impersonate a user, or inject signed code?\nWhere are the weak endpoints? Some devices will be easy to upgrade. Others won\u0026rsquo;t. Find the servers running old TLS stacks, the applications with hardcoded ciphers, the firmware that hasn\u0026rsquo;t seen an update since installation. Catalogue them now, because they\u0026rsquo;ll take the longest to fix.\nWhat\u0026rsquo;s happening on the network? Trace the paths your data travels. Is encryption applied end-to-end, or are there decryption points where traffic sits in the clear? Do third-party integrations introduce cryptography you don\u0026rsquo;t control?\nWhere is crypto-agility possible? Some systems were designed to swap algorithms. Most weren\u0026rsquo;t. Identify which ones can be reconfigured and which need to be rebuilt. That distinction will determine your migration timeline more than anything else.\nHow do legacy and OT devices fit in? These are the hardest problem. Embedded devices with cryptographic functions burned into silicon. Industrial controllers that can\u0026rsquo;t be patched without a production outage. Equipment from vendors who have no post-quantum roadmap. You may not be able to fix these on the same schedule as your web servers, but you need to know they\u0026rsquo;re there so they don\u0026rsquo;t get forgotten.\nThe inventory is never finished # A one-time cryptographic audit has a shelf life measured in weeks. Certificates expire. Keys rotate. Code ships. New services come online. If your inventory lives in a static document, it\u0026rsquo;s already wrong by the time you finish reading it.\nThe goal is continuous discovery. Wire the scanning tools into the systems that already manage your infrastructure — CI/CD pipelines, asset databases, monitoring platforms. When something changes, the inventory should reflect it. When something appears that shouldn\u0026rsquo;t — a self-signed certificate on a production endpoint, a legacy cipher enabled after an update — the right people should know immediately.\nNone of this is glamorous. Inventory work rarely is. But it\u0026rsquo;s the prerequisite for every decision that follows. You can\u0026rsquo;t prioritise a migration if you don\u0026rsquo;t know what you\u0026rsquo;re migrating. You can\u0026rsquo;t measure progress if you don\u0026rsquo;t know where you started. And you can\u0026rsquo;t claim quantum readiness if you never did the work to find out what you were running in the first place.\nThis chapter describes the foundation. The chapters that follow build on it.\n","date":"21 October 2026","externalUrl":null,"permalink":"/posts/crypto-inventory/","section":"Blog","summary":"The first thing you learn in any migration project is that you can’t secure what you can’t see. Quantum readiness is no different. Before anyone upgrades an algorithm or swaps a certificate, the organisation has to answer a much simpler question: where is the cryptography actually sitting?\n","title":"Finding Where Encryption Lives","type":"posts"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/inventory/","section":"Tags","summary":"","title":"Inventory","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/post-quantum/","section":"Tags","summary":"","title":"Post-Quantum","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/series/post-quantum-cryptography/","section":"Series","summary":"","title":"Post-Quantum Cryptography","type":"series"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/post-quantum-cryptography/","section":"Tags","summary":"","title":"Post-Quantum-Cryptography","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/quantum-computing/","section":"Tags","summary":"","title":"Quantum-Computing","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/strategy/","section":"Tags","summary":"","title":"Strategy","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/tls/","section":"Tags","summary":"","title":"Tls","type":"tags"},{"content":"Security headers are the front door. TLS is the lock. I built sec-headers to check the headers; now here\u0026rsquo;s tls-audit to check the lock.\nIt\u0026rsquo;s a Python CLI that connects to a host and reports what it actually negotiates — not what the config file claims. The certificate, which protocol versions are enabled, whether known-weak ciphers are accepted, and whether anything post-quantum is in play.\nWhat it checks # Check What it reports Certificate subject, issuer, serial, expiry, key type/size, signature algorithm, SANs Chain whether the certificate chain validates against the system trust store Protocols which of TLS 1.0 / 1.1 / 1.2 / 1.3 the server accepts Weak ciphers whether RC4, 3DES, NULL, EXPORT, or anonymous ciphers are accepted Post-quantum whether any PQC key exchange or signature is detected Why I built this # sec-headers answers \u0026ldquo;are your headers doing anything?\u0026rdquo; It doesn\u0026rsquo;t tell you the certificate expires next week, that TLS 1.0 is still switched on, or that a weak cipher is being accepted. Those are transport-layer problems, and they need their own tool.\nThere\u0026rsquo;s a second reason. I\u0026rsquo;ve been writing about post-quantum cryptography — the harvest-now-decrypt-later problem, where encrypted traffic gets recorded today and cracked once a quantum computer is available. I wanted a tool that answers the practical version of that question: \u0026ldquo;Is my traffic quantum-safe right now?\u0026rdquo; For almost everyone the honest answer is no, and the tool says so instead of pretending otherwise.\nWhat it looks like # This is a real run against this site:\n━━━ barryocallaghan.com:443 (2606:4700:3033::6815:24f5) ━━━ Certificate Subject barryocallaghan.com Issuer WE1 Serial 222020264202809002776278328253571420674 Expiry ✓ 89 days remaining Key EC 256 bits (secp256r1) Signature ✓ ecdsa-with-SHA256 SANs barryocallaghan.com Chain ✓ validates Protocols ✓ TLS 1.0 disabled ✓ TLS 1.1 disabled ✓ TLS 1.2 enabled ✓ TLS 1.3 enabled Weak ciphers (TLS 1.2) • RC4 untestable (unavailable in local OpenSSL) • 3DES untestable (unavailable in local OpenSSL) ✓ NULL not accepted • EXPORT untestable (unavailable in local OpenSSL) ✓ ANON not accepted Post-quantum ⚠ classical key exchange (no PQC detected) → traffic is exposed to harvest-now-decrypt-later Result: ✓ clean (1 warning(s)) Every line is a claim the tool verified over the wire, not a guess from a config file.\nThe post-quantum bit # That last section is the one I care most about. TLS as deployed today uses classical key exchange (RSA, ECDHE). That means recorded ciphertext is a future liability — decryptable once a fault-tolerant quantum computer exists. tls-audit checks for any sign of post-quantum key exchange or signatures and reports what it finds. Today, that\u0026rsquo;s \u0026ldquo;classical\u0026rdquo; for effectively every site. As PQC rolls out, the tool will start flagging the ones that have moved.\nThe fix isn\u0026rsquo;t \u0026ldquo;switch on a flag.\u0026rdquo; It\u0026rsquo;s migrating key exchange to hybrid or ML-KEM-based schemes as implementations mature — the subject of Part 2 of the series. This tool is how you\u0026rsquo;ll verify that migration actually happened.\nHonest limits # I\u0026rsquo;d rather tell you what the tool can\u0026rsquo;t do than let you find out mid-audit:\nWeak-cipher detection depends on your OpenSSL. Modern OpenSSL 3.x builds removed RC4, 3DES, and EXPORT, so on those machines the tool reports untestable rather than guessing. (NULL and ANON are still available, so those get a definitive answer.) Post-quantum detection is basic. Python\u0026rsquo;s TLS stack doesn\u0026rsquo;t yet expose the negotiated key-exchange group, so detection is limited to cipher-suite and certificate-signature names. It correctly says \u0026ldquo;classical\u0026rdquo; for today\u0026rsquo;s sites, which is the point. This is a health check, not a lab-grade audit. If you need every cipher and extension enumerated, use testssl.sh or nmap --script ssl-enum-ciphers. tls-audit is for a fast, scriptable, honest answer — not a certification report.\nInstall and run # pip install git+https://github.com/barry-oc/tls-audit.git # Single host tls-audit example.com tls-audit example.com:8443 # Batch from a file (one host per line, # for comments) tls-audit -f hosts.txt # JSON for scripts and pipelines tls-audit example.com --json | jq \u0026#39;.[0].certificate.days_left\u0026#39; It exits 1 on any failure — expired cert, SHA-1 signature, sub-2048-bit RSA key, a chain that won\u0026rsquo;t validate, TLS 1.0/1.1 still on, or a weak cipher accepted — so it drops straight into CI.\n# GitHub Actions - name: Audit TLS run: | pip install git+https://github.com/barry-oc/tls-audit.git tls-audit staging.example.com Run it against your own host. github.com/barry-oc/tls-audit\nPull requests welcome — especially if you find a cipher or extension I\u0026rsquo;m not probing yet.\n","date":"21 October 2026","externalUrl":null,"permalink":"/posts/tls-audit-launch/","section":"Blog","summary":"Security headers are the front door. TLS is the lock. I built sec-headers to check the headers; now here’s tls-audit to check the lock.\nIt’s a Python CLI that connects to a host and reports what it actually negotiates — not what the config file claims. The certificate, which protocol versions are enabled, whether known-weak ciphers are accepted, and whether anything post-quantum is in play.\n","title":"tls-audit: Audit Any Host's TLS in One Command","type":"posts"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/tags/tooling/","section":"Tags","summary":"","title":"Tooling","type":"tags"},{"content":"","date":"21 October 2026","externalUrl":null,"permalink":"/categories/tools/","section":"Categories","summary":"","title":"Tools","type":"categories"},{"content":"","date":"20 October 2026","externalUrl":null,"permalink":"/tags/headers/","section":"Tags","summary":"","title":"Headers","type":"tags"},{"content":"","date":"20 October 2026","externalUrl":null,"permalink":"/tags/malware/","section":"Tags","summary":"","title":"Malware","type":"tags"},{"content":"Security headers are the cheapest defense you can deploy. They cost nothing, take minutes to configure, and block entire classes of attacks — XSS, clickjacking, MIME sniffing, SSL stripping. Yet most sites get them wrong, or don\u0026rsquo;t set them at all.\nI built sec-headers, a fast Python CLI that audits seven critical HTTP security headers on any website and gives you a straight A+ through F grade. Here\u0026rsquo;s how it works and why you should run it on your own stuff.\nThe seven headers that matter # Not all security headers are equal. I weighted mine by real-world impact:\nHeader Weight What it does Strict-Transport-Security ⭐⭐⭐⭐⭐ Enforces HTTPS; kills SSL stripping Content-Security-Policy ⭐⭐⭐⭐⭐ Your primary XSS and injection defense X-Content-Type-Options ⭐⭐⭐⭐ Blocks MIME-type sniffing attacks X-Frame-Options ⭐⭐⭐⭐ Clickjacking protection Referrer-Policy ⭐⭐⭐ Controls how much info leaks via referrer Permissions-Policy ⭐⭐⭐ Restricts browser feature/API access X-XSS-Protection ⭐⭐ Legacy XSS filter (CSP supersedes it) So Content-Security-Policy and Strict-Transport-Security each carry 5x the weight of X-XSS-Protection in the final grade. Missing HSTS hurts far more than a weak referrer policy — and it should.\nWhy I built this # I wanted a single command that answers the question: \u0026ldquo;Are these headers actually doing anything?\u0026rdquo;\nExisting tools either:\nRequire a browser extension (manual, doesn\u0026rsquo;t scale) Are SaaS with rate limits Give you a pass/fail without telling you why sec-headers is different. It\u0026rsquo;s a CLI-first, pipe-friendly tool that:\nWorks on any URL — give it one or a thousand Explains every finding — not just \u0026ldquo;fail,\u0026rdquo; but what\u0026rsquo;s wrong and how to fix it Outputs JSON — wire it into CI, scripts, or bug bounty reports Scores honestly — weighted grades that prioritize critical headers What it looks like # $ sec-headers https://example.com ━━━ https://example.com ━━━ Status: 200 │ Grade: B (82/100) │ Time: 234ms ✓ 4 pass ⚠ 2 warn ✗ 1 fail Header Status Detail ────────────────────────────── ──────── ────────────────────────────────────────── Strict-Transport-Security ✓ PASS max-age=31536000, includeSubDomains, preload Content-Security-Policy ⚠ WARN contains \u0026#39;unsafe-inline\u0026#39; X-Content-Type-Options ✓ PASS \u0026#39;nosniff\u0026#39; X-Frame-Options ✓ PASS DENY Referrer-Policy ✗ FAIL missing Permissions-Policy ⚠ WARN missing X-XSS-Protection ✓ PASS \u0026#39;1; mode=block\u0026#39; Every header gets a clear message: what\u0026rsquo;s right, what\u0026rsquo;s wrong, and what to do about it. No guesswork.\nInstall and run # pip install git+https://github.com/barry-oc/sec-headers.git # Single URL sec-headers https://yoursite.com # Pipe from other tools subfinder -d example.com | httpx -silent | sec-headers # Batch audit with JSON output sec-headers -f targets.txt --json | jq \u0026#39;.[] | {url, grade}\u0026#39; The most common problems (so far) # Running this against a handful of sites, patterns emerge fast:\nMissing Referrer-Policy — by far the most common failure. Set it to strict-origin-when-cross-origin and move on. CSP with unsafe-inline — CSP exists but is toothless. If you\u0026rsquo;re loading third-party scripts with inline handlers, you haven\u0026rsquo;t really adopted CSP. Permissions-Policy absence — almost nobody sets this. If your site doesn\u0026rsquo;t use the camera, microphone, or geolocation, say so explicitly. HSTS without includeSubDomains — max-age looks good, but subdomains are left unprotected. Each of these is a 5-minute fix. The hard part is knowing they exist.\nWire it into CI # The tool exits with code 1 if any header fails, so it slots right into a pipeline:\n# GitHub Actions - name: Audit security headers run: | pip install git+https://github.com/barry-oc/sec-headers.git sec-headers https://staging.example.com Bust the build if your staging environment drops HSTS during a deploy. You\u0026rsquo;ll catch regressions before they hit prod.\nRun it on your own site. github.com/barry-oc/sec-headers\nPull requests and bug reports welcome — especially if you find a weird edge case in a header I haven\u0026rsquo;t seen yet.\n","date":"20 October 2026","externalUrl":null,"permalink":"/posts/sec-headers-launch/","section":"Blog","summary":"Security headers are the cheapest defense you can deploy. They cost nothing, take minutes to configure, and block entire classes of attacks — XSS, clickjacking, MIME sniffing, SSL stripping. Yet most sites get them wrong, or don’t set them at all.\n","title":"sec-headers: Audit Your Security Headers in One Command","type":"posts"},{"content":"","date":"20 October 2026","externalUrl":null,"permalink":"/tags/security-strategy/","section":"Tags","summary":"","title":"Security-Strategy","type":"tags"},{"content":"Most threats in cybersecurity give you a sign. A phishing link lands in an inbox. A port scanner rattles the perimeter. A CVE drops with a severity score attached. Something happens, and you get a window to react.\nThe quantum threat doesn\u0026rsquo;t announce itself. It arrives as a change in physics that quietly undermines the mathematics holding up secure websites, signed software, encrypted communication, and most of the digital trust infrastructure the world runs on. There is no patch. There is no log entry. One day the algorithms stop being reliable, and by the time anyone notices, the data they were supposed to protect may have already been collected, stored, and broken.\nThis chapter is about understanding what that means before it happens. Because the migration away from vulnerable cryptography is not something you can compress into a weekend sprint after the fact.\nHow quantum computers are different # You don\u0026rsquo;t need the physics. What matters is that these machines don\u0026rsquo;t solve problems the way conventional computers do — one step, then the next, working through possibilities in sequence.\nThink of a combination lock. A classical computer tries each number in turn: 0000, 0001, 0002, all the way up. A quantum computer, given the right algorithm, can explore all the combinations simultaneously and land on the answer.\nFor most types of calculation, that\u0026rsquo;s a curiosity. For the specific mathematics that secures nearly all online communication — the integer factorisation behind RSA, the discrete logarithm problem behind Diffie-Hellman and elliptic curve cryptography — it is a direct threat. Problems that would take a conventional machine longer than the age of the universe become solvable in practical timeframes on a large enough quantum device.\nWhen this arrives # The moment a quantum computer grows capable of breaking today\u0026rsquo;s public-key cryptography is often called Q-Day. Forecasts range from the early 2030s to the late 2040s, depending on who you ask and which technical hurdles they expect to slow progress down.\nThe precise year matters less than people assume. What matters is how long your data needs to stay private. A credit card number has a short shelf life. A patient\u0026rsquo;s medical history, a corporate acquisition document, or a diplomatic cable might need to remain confidential for thirty years or more. If your organisation holds that kind of information, you are already inside the window where the data you protect today could be decrypted before its useful life is over — no matter which forecast turns out to be right.\nThe attack that doesn\u0026rsquo;t wait # There is a second dimension to the risk that often gets overlooked, and it changes the urgency of the whole conversation.\nEncrypted data can be copied now and decrypted later. An adversary does not need a working quantum computer to begin. They need access to encrypted traffic or stored ciphertext. They collect it. They hold it. When the capability arrives, they unlock it.\nThis is called harvest now, decrypt later, and it is not theoretical. Nation-state actors have been recorded intercepting and archiving encrypted communications for years. The economics are straightforward: storage is cheap, and data that retains value for a decade or more is worth sitting on.\nIt also means that upgrading your encryption today does not retroactively protect data that already left your network under older protection. If sensitive traffic was intercepted three years ago and stored, turning on post-quantum encryption tomorrow stops future collection but does nothing about the copy already sitting on someone else\u0026rsquo;s disk.\nWhat gets harvested is predictable. Anything with long-term value:\nMedical and insurance records — relevant for a person\u0026rsquo;s lifetime. Legal documents and contracts — significant for decades. Financial data — accounts, transactions, settlement records. Credentials and private communications — passwords, messages, internal discussions. There is a particular risk around digital certificates — the infrastructure that verifies websites are who they claim to be and that software updates originate from the vendor that signed them. If an attacker can forge certificates, they can impersonate legitimate services or distribute authenticated malware. That\u0026rsquo;s not a privacy breach. It\u0026rsquo;s a trust failure across the entire system.\nWhat actually breaks # It is tempting to frame this as a confidentiality problem: encrypted things become readable, so secrets leak. That is true, but it is the smaller half of the story.\nThe larger half is integrity. Digital signatures prove provenance. Certificates prove identity. Code signing proves software hasn\u0026rsquo;t been modified in transit. These are the mechanisms that let two parties who have never met do business online with confidence.\nWhen they stop working, the consequences extend well beyond exposed data:\nDocuments lose verifiability. A legal agreement, a notarised record, or a regulatory filing could have been altered — and there would be no cryptographic way to settle the question. Impersonation becomes undetectable. A forged certificate passes validation because the underlying mathematics no longer distinguishes real from fake. Software updates become untrustworthy. A signature that used to guarantee a patch came from the vendor now tells you nothing. None of this is happening at scale today. The point is that the raw material — encrypted traffic, signed binaries, certificate chains — is being stockpiled now. The pieces are already in position.\nWhere to begin # The practical response is not panic. It\u0026rsquo;s a sequence of deliberate steps.\nStart by finding where your organisation relies on the kind of cryptography that quantum computers attack — the public-key algorithms behind TLS, digital signatures, key exchange, and certificate validation. Then ask the harder question: which of those protections would still matter if they failed five or ten years from now? The assets where the answer is yes are your priority list.\nThe chapters that follow walk through that migration: locating your cryptographic dependencies, understanding which replacement algorithms have been standardised, testing them in real environments, and managing the transition without breaking the systems people depend on every day.\nThe short version: the risk is real but manageable. The work is to find the things that need protecting over the long term and start moving them onto quantum-resistant foundations before the old ones give way.\n","date":"20 October 2026","externalUrl":null,"permalink":"/posts/q-day/","section":"Blog","summary":"Most threats in cybersecurity give you a sign. A phishing link lands in an inbox. A port scanner rattles the perimeter. A CVE drops with a severity score attached. Something happens, and you get a window to react.\n","title":"The Day Encryption Stops Working","type":"posts"},{"content":"","date":"20 October 2026","externalUrl":null,"permalink":"/tags/virus-total/","section":"Tags","summary":"","title":"Virus-Total","type":"tags"},{"content":"If you handle suspicious files — malware samples, email attachments, downloads from sketchy URLs — you\u0026rsquo;ve done the dance: hash the file, open VirusTotal, paste the hash, wait, repeat. It\u0026rsquo;s slow, manual, and burns your attention on process instead of analysis.\nI built vt-scanner, a CLI that automates the entire workflow. Point it at a directory and it hashes every file, checks VirusTotal, caches results, and tells you what\u0026rsquo;s clean and what\u0026rsquo;s not. No browser tabs, no copy-paste, no wasted API calls.\nWhat it does # Three subcommands, each for a different workflow:\nscan — one-shot audit # vt-scanner scan ./malware-samples Hashes every file, checks VT, prints a verdict table:\nFILE VERDICT ENGINES NAME LAST SEEN ──────────────────────────────────── ────────── ──────── ─────────────────── ──── samples/legit-setup.exe CLEAN 0/72 setup_installer 2026-10-15 samples/backdoor.dll MALICIOUS 12/72 Trojan.Generic 2026-10-18 samples/unknown.bin UNKNOWN - - - Malicious files are highlighted in red, suspicious in yellow, clean in green. JSON output is available for scripting.\nmonitor — continuous watch # vt-scanner monitor ~/Downloads --interval 60 Monitors a directory forever. New or modified files get hashed and checked automatically. Good for a malware analysis VM, a shared download folder, or monitoring where you drop samples during triage.\ncache — don\u0026rsquo;t waste API calls # vt-scanner cache stats Every lookup is stored in a local SQLite database. If a file hasn\u0026rsquo;t changed (same path, same modification time), the cached result is reused — zero API hits. This is the main upgrade over the manual copy-paste workflow.\nInstall and run # pip install git+https://github.com/barry-oc/vt-scanner.git export VT_API_KEY=\u0026#34;your_key_here\u0026#34; vt-scanner scan ./samples vt-scanner monitor ./incoming --interval 30 VirusTotal free tier allows 4 requests per minute. The scanner spaces requests automatically — set --rate-limit if you have a higher-tier key.\nWhy I built this # The original version of this tool was a loop-and-sleep Python script I\u0026rsquo;d been using for months. It worked but had all the usual raw-script problems:\nAPI key hardcoded in the file time.sleep(30) between every request regardless of rate limit Results printed as unformatted Python objects No caching — same file checked 50 times Only SHA-256 The rewrite adds proper CLI design (argparse, three subcommands), structured caching (SQLite with path+mtime tracking), formatted output (color tables + JSON), and support for SHA-256, SHA-1, and MD5. Same core idea, but it doesn\u0026rsquo;t feel like a script someone duct-taped together at 2am.\nPipe it # JSON output makes it scriptable:\n# Find all malicious files vt-scanner scan ./samples --json | jq \u0026#39;.[] | select(.result.last_analysis_stats.malicious \u0026gt; 0)\u0026#39; # Export clean files to a list vt-scanner scan ./samples --json | jq -r \u0026#39;.[] | select(.result.last_analysis_stats.malicious == 0) | .path\u0026#39; \u0026gt; clean.txt Run it on your samples. github.com/barry-oc/vt-scanner\nPull requests and feature ideas welcome — especially if you have an edge case in your malware workflow I haven\u0026rsquo;t thought of yet.\n","date":"20 October 2026","externalUrl":null,"permalink":"/posts/vt-scanner-launch/","section":"Blog","summary":"If you handle suspicious files — malware samples, email attachments, downloads from sketchy URLs — you’ve done the dance: hash the file, open VirusTotal, paste the hash, wait, repeat. It’s slow, manual, and burns your attention on process instead of analysis.\n","title":"vt-scanner: Check Any File Against VirusTotal in One Command","type":"posts"},{"content":"","date":"20 October 2026","externalUrl":null,"permalink":"/tags/web-security/","section":"Tags","summary":"","title":"Web-Security","type":"tags"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"I build small, sharp, open-source security tools that solve problems I actually hit in the field. Each one is CLI-first, scriptable, and free — no SaaS dashboard, no browser extension, no signup. They slot into the same pipelines you already run.\nsec-headers # Audit HTTP security headers. Score A+ through F.\nA fast Python CLI that checks the seven security headers that matter most and gives you an honest, weighted grade — plus a plain-English fix for every finding.\nPython async CLI CI-ready What it does\nAudits HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and X-XSS-Protection Weighted scoring — a missing HSTS costs you more than a weak referrer policy Explains why each header matters and how to fix it JSON output for piping into CI, scripts, or bug bounty reports Exits non-zero on failure, so it breaks your build when staging regresses pip install git+https://github.com/barry-oc/sec-headers.git sec-headers https://yoursite.com → GitHub · Read the writeup\nvt-scanner # Check any file against VirusTotal — no browser tabs.\nA CLI that hashes files, queries VirusTotal, and caches every result in SQLite. Unchanged files never burn an API call twice. Three modes: scan, monitor, and cache.\nPython VirusTotal SQLite CLI What it does\nscan — hash a directory and print a color-coded verdict table monitor — watch a folder forever; new files get checked automatically cache — reuse results by path + modification time, zero wasted API hits SHA-256, SHA-1, and MD5 support JSON output for scripting; auto-spaces requests to respect rate limits pip install git+https://github.com/barry-oc/vt-scanner.git export VT_API_KEY=\u0026#34;your_key_here\u0026#34; vt-scanner scan ./samples → GitHub · Read the writeup\ntls-audit # Audit any host\u0026rsquo;s TLS, certificate, and post-quantum readiness.\nA Python CLI that connects to a host and reports what it actually negotiates — certificate details, protocol versions, weak-cipher acceptance, and whether any post-quantum crypto is in play.\nPython TLS cryptography CLI What it does\nParses the certificate: subject, issuer, expiry, key type/size, signature algorithm, SANs Verifies the chain against the system trust store Probes which of TLS 1.0 / 1.1 / 1.2 / 1.3 are accepted Tests RC4, 3DES, NULL, EXPORT, and anonymous cipher acceptance Flags whether any post-quantum key exchange or signature is detected JSON output; exits non-zero on any failure pip install git+https://github.com/barry-oc/tls-audit.git tls-audit yourhost.com → GitHub · Read the writeup\nWant a tool? # If there\u0026rsquo;s a repetitive security task eating your time, I probably want to script it too. Open an issue or reach out — good ideas become the next tool on this page.\n","externalUrl":null,"permalink":"/projects/","section":"Barry O'Callaghan","summary":"I build small, sharp, open-source security tools that solve problems I actually hit in the field. Each one is CLI-first, scriptable, and free — no SaaS dashboard, no browser extension, no signup. They slot into the same pipelines you already run.\n","title":"Projects","type":"page"},{"content":"Security isn\u0026rsquo;t learned in silence. I speak at conferences, deliver ISC2 workshops, and run private sessions for organizations navigating the intersection of offensive security, AI, and incident response.\nUpcoming # No upcoming talks announced. Get in touch if you\u0026rsquo;d like me to speak at your event.\nPast # Event Topic Date Your talks will appear here. — — Topics I cover # Offensive AI — how threat actors weaponise AI, and what defenders can do about it Red teaming \u0026amp; penetration testing — modern approaches to application and infrastructure testing Security architecture \u0026amp; incident response — designing resilient systems and guiding organizations through critical events Cyber leadership \u0026amp; project management — strategy, governance, and delivering complex international programs ISC2 certification prep — CISSP, CCSP, and AI strategy workshops Blog posts \u0026amp; publications # Blog # The Day Encryption Stops Working — the quantum threat in plain language (Part 1 of the Post-Quantum Cryptography series) sec-headers: Audit Your Security Headers in One Command — check your site\u0026rsquo;s security headers in one command vt-scanner: Check Any File Against VirusTotal in One Command — scan any file against VirusTotal Publications # Post-quantum cryptography — a practitioner\u0026rsquo;s guide. Forthcoming. Booking # I\u0026rsquo;m available for keynotes, panels, workshops, and private training sessions. Reach me at me@barryocallaghan.com.\n","externalUrl":null,"permalink":"/speaking/","section":"Speaking \u0026 Presentations","summary":"Security isn’t learned in silence. I speak at conferences, deliver ISC2 workshops, and run private sessions for organizations navigating the intersection of offensive security, AI, and incident response.\nUpcoming # No upcoming talks announced. Get in touch if you’d like me to speak at your event.\n","title":"Speaking \u0026 Presentations","type":"speaking"}]