James Gorman helped wire the early internet, stood in a New York data center turning screwdrivers in the morning and pitched bankers in the boardroom that afternoon, and once told GE's leadership they could own the internet for 30 million dollars. They passed. Now he runs Hard to Hack, an advisory practice that builds security programs for small and mid-sized companies, then trains them up and leaves. He calls his clients graduates. Sam sat down with him to talk cybersecurity, the dot com crash, Y2K, CrowdStrike, AI, and why your network really is your net worth.
What You'll Hear
- Why Hard to Hack builds security programs, trains the team, then exits, and what James means when he calls clients graduates
- A horror story about an investment manager who lost long-term clients to a 10 percent underbid after his email and CRM were quietly read for months
- How a midsize manufacturer got ransomwared through a service account that was allowed to VPN in through the corporate network
- The CFO and CEO languages, and how IT leaders should frame spend as cost replacement and risk insurance instead of asking for new tools
- The 200 million dollar food processor with 30 overlapping security tools that never talked to each other
- James joining the Navy in 1986, training in cryptography, and installing an encrypted TCP IP network on a ship in 1988
- How he almost sold GE on owning the internet for 30 million dollars in 1993, and what he built instead
- Parallels between 1995 internet investment and 2026 AI spend, and why he thinks a correction is coming
- Why Y2K, the CrowdStrike outage, and aging COBOL and Fortran code all trace back to the same deploy-too-fast problem
The Hard to Hack model and why certification is not security
James Gorman did not build Hard to Hack to sell tools. He built it to build security programs. A client calls because a customer is requiring SOC 2, HIPAA, PCI, or CMMC. James goes in, writes the program, trains the people, and leaves. He calls the clients graduates.
The distinction he drew early in the conversation matters. A certification does not make you secure. You can be compliant and still get hit. The reverse is more useful. If you are actually secure, the compliance part follows naturally. So his work starts with the basics of cybersecurity governance, asset inventory, reconnaissance, access control, then builds the program on top of that foundation.
Because James does not resell software or services, his referrals carry weight. If he tells a client to bring in a specific backup provider or migration partner, he makes nothing on the deal. That posture changes the conversation. When he asks a CTO or head of IT when they last restored from backup, the answer is almost always no, we have never tested that, and James is not trying to upsell them on anything. He is trying to get the basic blocking and tackling done before a holiday weekend ransomware attack forces the issue.
Two cybersecurity horror stories every small business owner needs to hear
The first horror story is about an investment manager James calls Barry. Barry was sharp, but he used the same email and same password everywhere, with no multifactor authentication anywhere except his banks. His credentials leaked on the dark web. An attacker started reading his email and his CRM, learned his proposal pricing, and sold the same services to three of Barry's renewals at 10 percent below his number. Barry lost the clients before he understood what had happened. James rebuilt the program, deployed a password manager, turned on multifactor everywhere. The long-term clients were already gone.
The second story is a midsize manufacturer. They had ISO 27001. They had multifactor. They had a VPN. But they had exceptions. A service account was a member of Active Directory, which meant it could VPN in. An attacker grabbed those credentials, dropped a payload, and kicked off a ransomware attack over a holiday weekend. An alert system administrator caught the weird activity early and isolated the server. The company spent significant time and money to recover, but did not have to pay the ransom because their backups were good, including an old backup system they had never turned off. The lesson James keeps coming back to is simple. The exceptions are what kill you.
Talking to the CEO and CFO in their own languages
James spent a chunk of the conversation on something most IT leaders get wrong. The CEO sees IT as a cost center. Objectively, it is. But the right frame is insurance. You would not run a business without the right policies, and cybersecurity is the same class of spend.
His advice to IT leaders is to stop asking for new tools and start talking in cost replacement. One hire in a security operations role runs 150 to 200 thousand dollars fully loaded and gets you eight hours a day, five days a week, with gaps for sick days and vacation. The same spend on a managed security service gets you four people, 24 by 7. That is a cost replacement argument, not a tool request.
The same logic works on licensing. Upgrading Microsoft tenants into Intune can let you shrink on-prem server footprint and delay hires. A 50 thousand dollar upgrade looks big until you surface the 30 thousand you were already spending and the hire you no longer need for six to twelve months. James tells IT leaders to offset costs when they talk to the CFO and offset risk when they talk to the CEO. That is how technical people get decisions moved in board meetings.
SaaS sprawl and the 80 percent you do not use
James walked through what he sees inside most mid-market tech stacks. A company buys Salesforce or Okta or Microsoft at a tier built for the Fortune 500 and uses maybe 20 percent of the functionality. The other 80 percent is still there. You are paying for it, and more importantly, you are exposed to it. A vulnerability in a feature you do not use is still a vulnerability that can hit you.
He described a 200 million dollar food processor with 30 tools labeled security or IT. None of them talked to each other. None of them were configured. They were bought because a vendor said they were needed, or because the previous IT leader insisted on them before being forced out. A platform like Splunk can technically replace a dozen tools, but only if you have three engineers who know how to code against it. A mid-sized manufacturer whose real job is making product does not have that bench.
Sam and James agreed that for a small clinic with four doctors and fifteen employees, you probably need three tools. An antivirus with XDR, email scanning, and firewalls. A 100 person clinic needs more. The point is not a fixed number. The point is configuring the handful you actually use well, rather than collecting dashboards nobody reads.
From anti-pirate to internet pioneer
The middle of the conversation turned into a quick tour of forty years of technology history through James's own career. At seventeen his father told him he could put four kids through college and James was the one who would make it without school. So James joined the Navy, trained as an electronics technician, picked cryptographic school as his secondary, and in 1988 helped install one of the first satellite encrypted TCP IP networks on a Navy ship, years before most of the world had heard of TCP IP.
He got out in 1992, joined GE Information Services, and worked on Genie, one of the early competitors to AOL and CompuServe. When UUNET came online as a way to carry Unix to Unix email onto the public internet, James ran the numbers and pitched GE's leadership that they could own the core internet plumbing for 30 million dollars. He was told it was a fad. He left, started Planetcom selling dial-up and internet consulting, and ended up building C-SPAN's first internet broadcast. Their first live stream capped at twelve simultaneous subscribers or the whole thing fell over. He wrote a Perl script that grabbed a JPEG off their video feed every 90 seconds and posted it to the homepage so viewers had a picture of Chuck Schumer or Bob Dole to go with the audio.
Then came the CLEC. James was CTO of a competitive local exchange carrier that built out networks in 22 US cities, raised 300 million dollars, spent 350 million, and got caught in the dot com crash when the music stopped. He ended up unemployed with months of runway, called his network, and had a new role as someone's boss inside a month and a half. That is where the lesson he keeps repeating took hold. Your network is your net worth.
Y2K, CrowdStrike, and what AI spend looks like from someone who lived through 1995
James has lived through enough technology cycles to have strong opinions on the current one. On Y2K, the risk was real. Infrastructure written in COBOL and Fortran in the 1950s, 60s, and 70s used two digit dates, and the original programmers were retired or dead. The fix was brute force, and a lot of people made a lot of money converting dates to four digits. Was it overblown in the public imagination? Yes. Was the underlying risk real? Also yes. And a lot of that old code is still running power, water, sewage, and aviation.
He connected that to the CrowdStrike outage that grounded most of the airlines. In his read, CrowdStrike and Microsoft had an agreement that virus signatures could ship without full regression testing against the Windows kernel. That makes sense for signatures. It does not make sense for a binary change. When the binary update interacted badly with the kernel, the machines died in a way that required manual recovery. James's point was not that any one party was the villain. It was that modern IT keeps shipping third party code fast, and there are not enough gray-haired engineers in the room to slow things down and ask should we do that.
On AI, James thinks we are somewhere around 1995 on the internet curve. The infrastructure buildout is real. The applications are still ahead of us. Capital allocation is much more efficient than it was in the 90s, so the cycle is running faster and the correction, when it comes, will hit faster too. He does not think AI is a fad. He also does not think it replaces human judgment, original thought, or the trust that moves through a real network. A piece of advice he gave his daughter, who hates AI, stuck with Sam. You are not going to be replaced by AI. You are going to be replaced by a person using AI.
About James Gorman
James Gorman is the founder of Hard to Hack, an advisory and consultancy firm that builds security and compliance programs for small and mid-sized companies and then trains the team to run them. He is a US Navy veteran who trained in electronics and cryptography, helped build early internet infrastructure in the mid 1990s, served as CTO of a competitive local exchange carrier, and has worked inside payment processing, healthcare, and manufacturing as a fractional CISO. Hard to Hack