Reimagining 5G Security: AI-Powered Threat Detection in Network Slicing

As 5G networks rapidly scale across industries, their flexibility becomes a double-edged sword. One of the most innovative features—network slicing—enables operators to segment infrastructure into virtual networks tailored for enterprises, consumers, and billions of IoT devices. But with that agility comes risk: misconfigurations, lateral movement, and hidden anomalies can propagate quietly across slices, bypassing traditional security controls.

Given the rise of AI assistants, can we apply them to the realm of 5G? What if your AI assistant could not just read logs, but understand them? Not just see dashboards, but interpret them?

The Problem: Complexity at Scale

Security analysts face fragmented telemetry: logs from the core (AMF, SMF, UPF), YAML configs for slice definitions, dashboards showing QoS metrics, and endless alerts. Stitching this together is like defusing a bomb in the dark—while the clock ticks across multiple layers of the network.


Using Multimodal AI to perform Threat Analysis

Any multi-modal AI model has the capability to perform reasoning, making sense of logs, screenshots, config files, and natural language queries in one cohesive frame.

Here’s what that looks like in a 5G environment:

  • Log Intelligence: LLMs reads structured and unstructured logs to detect policy drift, failed authentications, or insecure slice configurations.

  • Config Auditing: It parses YAML/JSON policies to flag QoS mismatches, excessive access, or unintended lateral movement vectors.

  • Visual Analysis: A screenshot from your OSS/BSS dashboard can be interpreted based on process trees, red flags KPI spikes, and identifies service degradation—just like a human would.

  • Analyst Copilot: Ask in plain English: “Why is slice 3003 overloading?” The LLM model should respond with a root cause, a timeline, and remediation steps, all mapped to MITRE ATT&CK.


Sample Output:

“Slice 3003 shows excessive uplink usage due to a misapplied QoS policy update pushed via SMF. Traffic surge traced to IoT segment Z. Suggest rollback to baseline config v1.14 and apply rate-limiting to affected UE group.”


This AI-enhanced threat detection model can be integrated directly into your SOC stack—with LLM powering a chat-based interface, reading from your SIEM/SOAR, and even interpreting your dashboard screenshots.

If you’re an operator, CSP, or security leader staring down the complexity of 5G multi-modal LLMs can help you unpack, interpret and efficiently analyse and report Threats in your 5G network.


Let’s stop treating 5G security like a fire drill. With the right AI, it becomes a science.

Security in Developer first organization…

Security in an Agile, Developer First organization is a constant ”tug-of-war” between “more security controls vs more developer usability”. The reason for this is primarily the need of Security professionals to maintain control over the “hacky” by nature developers. I am a big fan of Mordoc and the comic strip below shows exactly how this tug-of-war is:

Developers typically use a lot of tools in their machines like:

  1. Build Tools (iOS, Android EMU, IDE, VM, Containers etc.)
  2. Browsers
  3. Repo tools constantly updating
  4. Testing tools.

On such machines, there is always a risk of developers being the target to steal source code or sensitive information. In order to protect these developers, Security teams become overzealous and implement several security tools like Endpoint Security solutions (AV, EDR, HIDS etc.) and Compliance tools (DLP, Web Proxy, Patching, logging etc.).

A typical machine that has all the security tools installed and running looks something like this. This pattern is true across typical enterprise organizations.

The question always is – Where is the balance between Security controls vs Developer productivity?

I gave a talk at a conference on this topic and the slides are available here.  There are various strategies we can employ to secure the developer machines or in general any enterprise computing asset. Some of the innovative ways (they are real and implementable) we can use are described with examples. I thoroughly enjoyed working on this talk and all the associated research that went with it.

 

 

Please leave your comments below. Until next time!!!

Is the SIEM dead?

change siem technology

It has been several years since SIEM emerged into the Security industry as an “Security Alerting” system. Since then, it has grown into a huge market with several vendors like ArcSight , QRadar, Splunk, Nitro, becoming successful since they were the first movers. Today, in 2020, they are becoming more and more obsolete. While people still buy SIEM for compliance needs, the real question to ask  is “Is the SIEM dead?”

What does a SIEM do?

SIEM by definition does the following:

  1. Log Collection from multiple devices/vendors
  2. Log Parsing and normalization into proprietary formats
  3. Log Aggregation
  4. Log Storage across a variety of data stores
  5. Rules Engine
  6. Management workflows
  7. API Driven Integration

Every vendor does all the above in different ways with varying degree of efficiency. However all the vendors have some common issues as well:

  • Poor Scalability: By definition, SIEM products scale very well in the Log Collection and Aggregation department. However, when it comes to Correlation, the SIEM falls short on Scale. Use case based Correlation rules, Log Filtering, Tuning etc need to be performed with ruthless focus on minimizing the need to scale the Correlation engine. While “on paper” vendors claim their correlation engines can be scaled, however, in practical use and effectiveness they fail.
  • Poor Intelligence: Contrary to popular belief, the Rules engine has no intelligence at all. All out of the box rules are stock compliance driven or basic security best practice driven. The pattern recognition rules are so archaic that seldom do organization detect any malicious attacker in the network using them.
  • Limited scope: Outside of Security operations centers (SOC), there is not much of a scope for SIEM to be relevant and valuable. This is primarily because while they are good at alarm based event management, they are miserable at “Event Searches” and “Reporting” thereby making it less and less attractive outside of the SOC realm.
  • Steep Learning curve: Every SIEM product  suffers from the steep learning curve. The learning curve on “General Use” is comparatively easy however, the “Power Use” and “Admin” is steep. Often times organization rely on a very small set of people (often 1 person) who is an expert on the product to keep this beast of a system up and running.
  • Maintenance Nightmare: The more you scale the SIEM, the more the maintenance needed to keep it up and running. This is especially a huge problem when you have mission critical functions depending on alerting and monitoring from SIEM. The amount of engineering resources burnt on this is significant.
  • Poor Analytics: While the SIEM vendors claim to be “Analytics” providers, what they provide is sub-par. Analytics requires the ability to analyse large volumes of data and run meaningful queries, however, most of the SIEM vendors because of “Poor scalability” , can’t process, store and provide analytical output on large volumes of data. Splunk for sure is an exception on this point as they are an Analytics platform first and a SIEM (poorly) later.
  • Poor ITSM capabilities: Again, SIEM vendors don’t do cases management as well as ITSM tools, thereby relying on 3rd party integrations which often times is a “one-way” integration, meaning cases can be created, but updates cannot be tracked in return.
  • Poor Automation: Reliance on 3rd party automation & response tools makes the SIEM ecosystem even more complex.

There are probably a few more issues depending on the SIEM vendors we see, but in general the above are the most common ones.

So the question is “Is the SIEM dead”??

Let me know in the comments section

Achieve Nirvana in Information Security

Follow

Get every new post delivered to your Inbox

Join other followers: