Breaking the Fourth Wall of Cybersecurity

This is something most security operations programs, especially Managed SOC and MDR providers, are TERRIFIED to do, but Wirespeed leans into it.

#What is the Fourth Wall?

In dramatic productions, the “Fourth Wall” is the imaginary boundary between the actors and the audience. In stage plays, actors look out in the direction of the Fourth Wall, but direct engagement with the audience is traditionally forbidden. In modern drama, especially comedy movies and television, actors sometimes “break the fourth wall” with direct engagement of the audience to create a more intimate connection to know what the character is thinking.

In Ferris Bueller’s Day Off, main character Ferris Bueller starts the movie with a monologue directly at the camera, giving you his direct thoughts and shaping his character. Later in the movie, Ferris would pull away from the group, look directly at the camera, and again make that direct connection.

Mockumentary-style TV show, The Office, did this all the time. Characters were often pulled into a smaller room with direct camera interviews, or you might catch Jim Halpert looking directly at the camera in the larger room settings, so you could juxtapose his sanity with the comically-stupid choices his coworkers made.

The Office: Jim Halpert Breaking the Fourth Wall

#What is the Cybersecurity Fourth Wall?

In the world of cybersecurity, our “audience” is our collection of “users,” who we protect. For nearly three decades, “experts,” whether in the next room or in an entirely different city, remotely reviewed security events, generated by these users we protect, and made decisions about them from afar. As an industry, we have tried everything to avoid talking to users:

• Using statistics and analytics to make guesses about whether an action, such as executing a sketchy process, making a security-impacting change, or logging in from an unexpected location, is malicious or benign
• Leveraging large data sets to enrich events to see if similar historical events were malicious or benign
• Sharing information among other cybersecurity practitioners, who also didn’t talk to users, about whether something is malicious or benign
• Using Machine Learning when we’re tired of guesses, but still not ready to talk to users
• Asking Large Language Models (LLMs) to make guesses … and yep … still not talking to users

Our Fourth Wall is strong. There’s nothing wrong with most of those things; we should probably do most of them, but we shouldn’t be scared to break the fourth wall when that really is the best way to get a definitive answer (we call them “verdicts”) on detections.

As an industry, we tend to only Break the Cyber Fourth Wall in a couple situations:

• When an enterprise user needs to go through training & acknowledge policies
• When their risky requests to bend a security policy or rule are denied
• During a major incident, when there’s no other choice but to finally muster up the energy to talk to them about what they did or experienced

#Not Breaking the Fourth Wall Creates an Analyst Dilemma

For so many types of alerts, there’s only so much statistical, analytical, ML, LLM cowbell you can throw at the case to analyze it, before you reach the typical analyst dilemma:

1. I could escalate, be wrong, and annoy the customer.
2. But if I dismiss, this could be a breach in progress.

The analyst is often left to guess or flip a coin. This is one of many reasons why we love SOC analysts, especially MSSP SOC Analysts. They have to make tough decisions!

#Why is Breaking the Fourth Wall of Cyber so Scary?

For most MDR/MSSP providers, it’s scary for two reasons: liability and time.

#1. Liability

If you’ve ever worked at a very small, growing company, then you’ve experienced a phenomenon that happens around 200 or so employees: you start to not know everyone. Now, for MSPs and MSSPs, multiply that by a bigger number to account for all of the users at their customer organizations. There are too many for the Service Provider to know them all by name, face, and voice! How can the Service Provider really know they’re talking to the right Jane Doe when they reach out? Answer: they can’t. So the liability is too big of a concern. The Service Provider simply cannot take a risk that they’re getting the disinformation from a threat actor who is masquerading as a victim user at a customer organization.

For organizations big enough to have their own internal SOC, they’re likely well past the limit of the number of people someone can know, so the problem is the same.

#2. Time

Trying to track down Jane Doe, wherever in the world she is at any given time of day, while managing a queue of alerts is extremely difficult to do. There’s pressure to get back to the queue of alerts to work the next one, so at best, only a few minutes can be spent pausing to find Jane and talk to her. If Jane doesn’t answer the phone and it rolls to voicemail, then what? What if Jane calls back hours later, after shift change? The next shift’s analysts will have to find the case, read the notes to become acclimated, then explain why the call happened in the first place. That’s a bunch of time that could be spent managing the alert queue. So, it’s a distraction. It might be good to do in the name of customer service, but it’s not reliable enough for working cases quickly.

I said there are two reasons but there really is a third reason as well:

#3. Introverts

Cybersecurity, like most technical job roles, is full of introverts. They picked this job for a reason: they don’t want to talk to users. If they’re asked or told to talk to Jane Doe, it may come with anxious social pressure. They may put it off, doing other tasks that they know are less important than finding out the answer from Jane. If only she would answer over Slack, maybe that would alleviate the introvert’s anxiety? But if you did talk to Jane over Slack, how would you know it’s the real Jane Doe?

#Wirespeed Breaks the Fourth Wall Daily

We are not scared to break the Fourth Wall of Cybersecurity. We lean into it, primarily because we know and empathize with the amount of work other MDRs leave on the security teams at their customers.

If an organization pays an MDR provider to “investigate” cases, and a case only provides a single lead (i.e. to talk to the user), but the MDR Provider instead says: “Here is a case escalation. Hot potato! You ask the user!” Then who is really doing the investigation?

If a case needs to verify with a victim user what they saw or experienced, but the MDR Provider says: “Here is a case escalation. Another hot potato! Go ask the user what happened. If they say X, then close the case, but if they say Y, invoke your incident response procedures. Good luck!” Again, who is doing the investigation? How is this helpful? What if the Security Team member who receives the case is another introvert and delays reaching out to the victim simply out of social anxiety or awkwardness? Every second that someone doesn’t ask the user could be an extra second for a threat actor to persist behind a stolen credential or in malware.

#When Wirespeed Breaks the Fourth Wall

We will break the Fourth Wall when there’s no better way to get an answer, such as:

• For a suspicious login or unusual/impossible travel
• When a technical user does something suspicious, like install an application on a server that has a neutral file reputation, but an EDR heuristic thinks it could possibly do something dangerous, like discovering credentials, key strokes, etc.
• To confirm a victim user did or did not expose credentials to a phish
• When a RMM (Remote Monitoring & Management) tool is used suspiciously
• When security-impacting configuration changes are made

Basically, if we were working the case manually, and thought the information we need to know to determine if the activity is actionable or not must come from the user, we will ask them, programmatically.

#We also Break the Fourth Wall for Resolution

In the spirit of never leaving work on the plates of the security admins at our customers that we know we can do ourselves, we will also reach out to victim users after we know a case is actionable, in order to guide them through resolution. Situations like when a user’s credential was exposed in a third party data breach. We know it’s actionable, so let’s find out if the password was reused or not, and if so, rotate it. When done, close the case, don’t bother the security team (unless they’d also like to follow-up).

If we can automate the step and give the user as good or better of an experience, we’ll do it. 🙌

#How to tell when others are SCARED to Break the Fourth Wall

A really simple way to know this is if you see a super complicated blog post about how they took some alert data, twisted it around, munged it twice, graphed it to show the clusters, pushed it through a (making this up) Monte Carlo Simulation, or asked an LLM a complicated prompt that starts with “You’re a world-class cybersecurity expert about to analyze this alert…”

#See for yourself

Go spin up a 14 day trial (we’ll even triage all alerts from the past 90 days in seconds), integrate your favorite collaboration tool, and see for yourself how we break the fourth wall. Get Started!

You're still here? It's over. Go. Try Wirespeed for free. Go!

---

Want to know more about Wirespeed? Follow us on LinkedIn / X or start a FREE TRIAL today.