If you grew up watching Saturday Night Live in the 1970s, you know the Landshark. For the uninitiated, the premise is beautifully absurd: a shark knocks on apartment doors and, when the suspicious occupant asks who is there, tries increasingly ridiculous cover stories to gain entry. “Candygram.” “Flowers.” “Pizza delivery.” The joke lands because the tenant knows something is wrong, asks the right question, but somehow still ends up opening the door. It is funny because it is ridiculous. It is also, if you work in information security, uncomfortably familiar.
We spend a lot of time and energy in this industry talking about the importance of verifying identity. We train employees not to let tailgaters through badge-access doors. We run phishing simulations to remind staff that not every email from “IT Support” is legitimate. We preach Zero Trust until our voices give out. And yet when an actual incident is unfolding, when the pressure is high and the clock is ticking, the verification protocols that should be second nature have a funny habit of falling apart in one of two equally dangerous directions. Either people skip verification entirely because they are flustered, or they become so aggressively paranoid that they refuse to let the legitimate responders in. Both outcomes are bad. One of them tends to get far less attention than it deserves.
The Classic Setup: Skepticism as a Feature
To be clear, healthy skepticism is not the problem. It is a feature of good security thinking, not a bug. Security-aware employees who question unexpected access requests, who call back on known numbers to verify identities, and who refuse to be socially engineered into handing over credentials are doing exactly what we have trained them to do. We want that behavior. We have worked hard to cultivate it.
The Landshark skit works as a metaphor precisely because the tenant is right to be suspicious. Something is clearly off. The question is whether their response to that suspicion is calibrated to the actual risk—or whether it has tipped from productive skepticism into something that creates problems of its own.
When Paranoia Becomes the Incident
Here is the scenario that does not get written about enough. An incident is in progress. A legitimate external responder, a forensic firm or a MSSP incident response team retained by legal counsel, attempts to engage with the internal security team. Nobody was briefed they were coming. The retainer was signed in haste at 9 PM. The internal analyst who picks up the phone at midnight has never heard of the firm, has no way to verify the claim in the moment, and has spent three years being trained to be deeply suspicious of exactly this kind of unexpected contact.
So the analyst does what a good security professional does. They say no. They escalate. They ask for callbacks. They request documentation. They open a ticket. And while all of that is happening—while the verification bureaucracy is grinding away at 1 AM—the attacker who is still inside the environment is doing attacker things. Logs are rolling over. Volatile memory is evaporating. Evidence is disappearing. The window for preserving a clean forensic record is closing, one verification email at a time.
The attacker does not pause and wait politely while your team verifies the identity of the people trying to stop them. Time spent on unnecessary friction is time given as a gift to the adversary.
This is the Landshark problem in reverse. Instead of opening the door to someone who should not get in, the organization refuses to open the door for someone who absolutely should. The joke is no longer funny. The shark is already inside and has been for three days.
The Root Cause Is Not Paranoia. It Is the Absence of Protocol.
It is tempting to frame this as a culture problem—too much security awareness training, employees who are so primed for suspicion that they cannot shift gears. But that is not really what is happening. The analyst who refuses access at midnight is not making a bad judgment call. They are making a reasonable judgment call in the complete absence of the information they would need to make a good one. Nobody told them a firm had been retained. Nobody gave them a pre-authorized contact list. Nobody established a challenge-response protocol for exactly this scenario. Nobody drilled them on how to balance verification rigor with operational urgency during an active incident.
The failure is not the skepticism. The failure is the vacuum that the skepticism has to fill because no protocol exists to replace it.
Good incident response planning accounts for this explicitly. It pre-authorizes specific individuals and firms. It establishes out-of-band communication channels that cannot be spoofed by an attacker who has compromised internal email. It creates a pre-shared challenge phrase or code that external responders and internal teams can use to establish legitimacy in seconds rather than hours. It makes sure that the person who will be on call at midnight on a Saturday knows exactly who they are allowed to trust and how to verify them quickly.
The Verification Protocol That Actually Works
Let me be specific, because the abstract principle of “have a protocol” is not particularly useful. What does a workable identity verification protocol look like for incident response scenarios?
Skepticism With an Off Switch
The goal is not to make your team less skeptical. The goal is to give your team the tools they need so that their skepticism does not have to operate in a complete information vacuum at the worst possible moment. A security professional who has a clear protocol to follow does not have to choose between being rigorously paranoid and letting the right people in quickly. They can do both, because the protocol does the hard work for them. What about your end users? Do you have an established, communicated protocol for an end user to identify a member of the Information Security team? I have been in situations where verification of a member of my team or I has taken in excess of forty-five minutes to try to verify identities. When you are in containment mode, these minutes are deep cuts against an already stacked deck against you.
The Landshark works as a comedy sketch because the tenant has no framework for quickly distinguishing “suspicious stranger at the door” from “legitimate visitor I wasn’t expecting.” The absurdity escalates because the only tool available is an increasingly desperate application of vague suspicion. Your incident response team should not be in the same position. They should have a clear, practiced, pre-agreed method for answering the most important question in the first sixty seconds of an external engagement: is this person actually who they say they are?
Healthy paranoia is one of the most valuable traits a security professional can have. It is what keeps social engineers out, what keeps phishing clicks low, and what makes your team genuinely hard to fool. But even the most valuable trait has its limits, and in incident response, the limit is this: paranoia without protocol is just confusion with better branding. Build the protocols. Drill them before you need them. And the next time a Candygram shows up at your door at midnight claiming to be a forensic analyst, you will know exactly what to do.
