If you run a law firm, hold trade secrets, or store anything on a computer that has real value, you have probably hired a security firm. You probably pay them well. And you probably assume your data is protected.

This article walks through the structural reasons it might not be. Not because your security firm is incompetent or dishonest. Most are staffed by people who genuinely care about protecting their clients. The problem is deeper than any one firm. It is built into the business model, the software stack, the hardware, and the legal jurisdiction that the entire industry operates within.

Read the facts. Draw your own conclusions.

The Business Model

Most businesses hire a security firm the same way. You needed cyber liability insurance. Your insurance carrier gave you a list of approved vendors. You picked one. They ran scans, installed software, produced a report with green checkmarks, and sent you a bill.

Here is the question nobody asks: who is the security firm actually accountable to?

Your security firm’s status as an “approved vendor” depends on the insurance company. The insurance company requires specific tools, specific processes, specific documentation. The firm delivers what the insurance company requires. You pay for it. Everyone is happy.

Until there is a breach.

When a breach occurs, the insurance company reviews the documentation the security firm produced. They look for gaps between what was documented and what their policy requires. If they find one, and policies are written so they usually can, the claim is denied.

The security firm produced the documentation. You paid for it. And the insurance company used it to demonstrate non-compliance. The firm cannot push back without risking their approved vendor status. This is not a conspiracy. It is an incentive structure. The firm’s continued revenue depends on keeping the insurance company satisfied, not on winning your claim.

Some firms have recognized this conflict and restructured how they work. They answer directly to the client, independent of insurance relationships. Those firms exist. But they are the exception, not the standard.

Follow the Money

The incentive problem goes further when you look at who owns what.

Insurance companies are massive financial institutions. They hold investment portfolios worth billions. Those portfolios can include stakes in the same corporations that litigation firms are suing.

Consider the scenario: a law firm holding a billion-dollar case against a pharmaceutical company buys cyber insurance. The insurer has investment exposure to the defendant. The insurer mandates the security vendor. The security vendor runs on infrastructure the insurer approves. The law firm pays for all of it.

Nobody in this chain is structurally incentivized to protect the law firm’s case strategy. That does not mean anyone is actively sabotaging it. It means the incentive alignment is not what you would assume when you sign the contract.

The Software Problem

Now consider what your security firm actually installed on your systems.

Endpoint detection. Managed SIEM. Cloud-based monitoring. Dashboards with green and red indicators. Automated alerts. Monthly reports. All software.

Software running on an operating system you did not audit. Using libraries written by people you have never met. Compiled by tools you cannot verify. Updated through mechanisms that could be compromised. Sending telemetry to cloud servers you do not control.

Every piece of security software on your machine is another piece of software on your machine. Another attack surface. Another set of permissions. Another process with access to your files. Your security product has the same access to your data as the threat it claims to protect against. You gave it that access because someone with a certification told you it was best practice.

This is not unique to security software. It is how most proprietary software works. But when the software in question is specifically responsible for protecting your most sensitive data, the inability to independently verify what it does becomes a more significant concern.

The Microsoft Problem

This is where it moves from business model questions to architectural ones.

Microsoft was the first company named in the NSA’s PRISM program. That is not speculation. It was published in classified documents reported by The Washington Post, The Guardian, and every major news outlet in 2013. Microsoft has cooperated with intelligence agencies. This is documented history.

Microsoft Azure hosts the infrastructure for a large number of security firms, law firms, financial institutions, and government agencies. Microsoft 365 handles their communications. Active Directory manages their authentication. Windows Server runs their workloads.

FedRAMP certification, which many security firms highlight as a credential, does not mean your data is protected from government access. It means the cloud provider has demonstrated to the government that they can provide data in the format the government requires. It is a compliance certification for government accessibility, not a privacy guarantee.

Most security firms run their entire operation on this stack. Your case files, your communications, your monitoring dashboards. All on infrastructure built and operated by a company with a documented history of intelligence agency cooperation. Whether that concerns you depends on your threat model. But it is a fact your security firm should be discussing with you. Ask them if they have.

The Hardware Problem

Software is the visible layer. Hardware is the invisible one.

Every Intel processor manufactured in the last two decades contains the Intel Management Engine (ME). It is a separate computer inside your computer. It has its own operating system, its own network stack, its own MAC address. It can access your memory, your storage, and your network. It runs when your computer is off, as long as power is connected.

You cannot see it. You cannot audit it. You cannot turn it off.

The NSA has a custom version of the Management Engine firmware called HAP (High Assurance Platform) that allows them to disable it on their own systems. They can turn it off. You cannot.

That is in every machine in your office right now. Every server your security firm manages. Every laptop your attorneys carry into court.

And it extends beyond the CPU. Your GPU has closed firmware. Your network interface card has its own processor. Your SSD controller can store data invisibly. Your baseboard management controller has full system access independent of your operating system. Every component is running code you have never seen and cannot inspect.

Most security firms do not discuss this with their clients. Not because they are hiding it. Because they operate at the software layer. That is where the certifications are. The hardware layer is outside their training and outside the scope of what insurance companies require them to assess.

The Network Problem

Even if you accept every risk above, there is still the network.

Most security firms configure firewalls with default-allow policies and specific deny rules. Everything is permitted unless someone thought to block it specifically. A compromised component attempting to communicate with an external server gets through because nobody put that specific destination on the deny list. How could they? They do not know what their own hardware is doing at the firmware level.

The correct approach is default-deny. Nothing moves unless explicitly permitted. Every packet inspected. Every anomaly flagged. But that requires understanding every legitimate communication your systems need to make and whitelisting only those. It takes deep knowledge of the environment at every layer.

Most firms do not configure networks this way. It is difficult, time-consuming, and the insurance company does not require it. The compliance checkbox says “firewall installed.” It does not say “firewall configured to detect unauthorized firmware-level communications.”

What Default-Deny Actually Looks Like

Every network interface has a MAC address. Every device on your network announces itself. The foundation of real network security is simple: catalog every MAC address in your environment and only allow those devices on the network. Everything else is dead on arrival. No traffic in. No traffic out. It does not exist on your network.

New device? It goes through a provisioning process. Cataloged, verified, added to the whitelist. No exceptions.

That means if Intel ME tries to phone home from a MAC address you did not whitelist, it goes nowhere. If a compromised USB adapter starts broadcasting, it goes nowhere. If someone plugs in a rogue device, it goes nowhere.

But knowing what is on your network is only the first layer. You also need to control who each device can talk to.

Every whitelisted device gets a profile. Not just permission to exist on the network, but permission to communicate only with specific IPs, specific ports, and specific protocols. Nothing else.

  • Printers can talk to the print server. Nothing else.
  • Security cameras can talk to the NVR. Nothing else.
  • Workstations can talk to the services they need. Nothing else.
  • Servers can talk to the clients and services they serve. Nothing else.

If a whitelisted workstation suddenly tries to connect to an IP it has never talked to before, it is blocked and logged.

So now you have three layers of network security:

  1. Is this device allowed on the network? MAC whitelist. If the device is not cataloged, it does not get a connection.
  2. Is this device allowed to talk to that destination? Destination whitelist. Each device can only reach the specific services it needs.
  3. Is this traffic normal for this device? Behavioral baseline. If a device that normally sends 50 KB per hour suddenly starts pushing 5 GB, something changed.

The tools to do this exist. Managed switches with port security. 802.1X authentication. Network access control systems. IDS/IPS monitoring. Network segmentation with VLANs. None of it is exotic technology. It is all available today.

The reason most security firms do not implement it is because it requires mapping every single device and component in the environment, maintaining that inventory, building individual traffic profiles, and actively monitoring all of it. That is real work. The insurance company does not require it. So it does not get done.

What I Found on My Own Machine

I recently ran a security audit on my Mac. I documented everything I found in a separate article, but here is the summary.

A process called mediaanalysisd was consuming 9 GB of RAM running machine learning analysis on my files. Face detection. Object classification. Scene analysis. OCR. It runs on every boot. There is no toggle in System Settings. It runs with full user account permissions, meaning it has access to every file on the machine, including my proprietary source code and business documents.

I had iCloud turned off for files. The process kept running. Kept scanning. I killed it. It respawned. I disabled it through system controls. It came back. I had to use terminal commands that Apple never documented to finally stop it.

On top of that, macOS sets default directory permissions to 755. Every process on the machine can read your files, even ones not running under your account.

I also discovered that Docker Desktop, which I had uninstalled weeks earlier, left 17 zombie processes running on my machine. Including an AI agent actively communicating with Docker’s servers. On software I had already deleted.

A security firm monitoring my endpoints would not have caught any of this. They are not looking for it. mediaanalysisd is an Apple system process. It would not trigger an alert. Default 755 permissions are standard macOS behavior. Docker zombies would not match any threat signature.

I also discovered that every admin account on my Mac was silently pre-authorized for SSH, screen sharing, remote Apple events, and file sharing through hidden SACL groups. macOS maintains over 150 of these groups and System Settings shows you two. I built a free tool to make all of it visible: instem os-groups.

Full details: Did We Pay Apple To Spy On Us?

What Actual Security Looks Like

Security that addresses these layers does exist. It just does not look like what most firms sell.

  • Physical security. A facility with real access controls. Not a badge reader and a receptionist. Controlled physical access to every piece of hardware in the environment.
  • Architectural security. Default-deny networking. Every packet inspected. Every anomaly flagged. Nothing moves unless explicitly permitted.
  • Hardware awareness. Every component in the environment verified, baselined, and monitored. If a chip transmits an unauthorized signal, it is detected, isolated, and removed.
  • Jurisdictional awareness. Understanding where your data physically sits, what legal frameworks govern access to it, and who can compel your hosting provider to hand it over.
  • Open-source tooling. Software you can audit. Not software you trust because a vendor told you to. Tools like WireGuard for encrypted tunnels, Nextcloud for file storage, KeePassXC for credentials, Podman for containers without telemetry.
  • Direct accountability. Your security provider answers to you. Not to your insurance company. Not to a vendor list. Not to a compliance framework. To you.

Some firms build this way. They are out there. The question is whether yours is one of them.

Questions to Ask Your Security Firm

The next time your security firm sends you an invoice, ask them these questions:

  • Who selected you as our vendor? Us or our insurance company?
  • Can we audit the source code of the security software installed on our systems?
  • What cloud infrastructure does your monitoring platform run on, and in what jurisdiction?
  • Have you assessed the Intel Management Engine on the hardware in our environment?
  • Is our firewall configured as default-deny or default-allow?
  • Do you maintain a whitelist of every MAC address authorized on our network?
  • Does each device on our network have a traffic profile limiting what destinations it can reach?
  • Can you tell us every process on our machines making outbound network connections right now?
  • Do you know the firmware version of every network interface card in our environment?
  • What is your policy on disclosing incidents versus downplaying them?
  • When there is a breach, whose documentation do you produce? Ours or our insurance company’s?

These are not gotcha questions. They are the minimum you should know about your own security posture. A firm that understands architecture at every layer will welcome them.

If your firm cannot answer them, that does not necessarily mean they are bad at their job. It might mean the industry trained them to focus on the wrong things. But either way, you deserve answers.

You can start with your own machine. macOS maintains over 150 hidden groups that control which users are pre-authorized for remote services like SSH, screen sharing, and file sharing. Most of them are invisible in System Settings. We built a free tool called instem os-groups that shows you exactly what is wide open and what is one toggle away from going live.

The Bottom Line

The security industry is full of talented, well-intentioned people. The problem is not the people. It is the structure they operate within. Business models tied to insurance companies. Closed-source software that cannot be verified. Hardware with components that run code nobody can inspect. Network configurations that check compliance boxes without addressing real threats. Legal jurisdictions that allow secret court orders and gag provisions.

Most firms do not address these layers because most firms were never trained to think about them. The certifications do not cover them. The insurance companies do not require them. The compliance frameworks do not ask about them.

That does not make those gaps any less real.

You trusted someone with the security of your business. You deserve to know whether that trust is justified. Not by a dashboard with green checkmarks, but by architecture you can verify, accountability you can enforce, and answers to the questions that actually matter.

The best security firms will welcome the hard questions. That is how you find them.