DEV Community: Alexandre Viau

Incorporating LLMs Into Cybersecurity

Alexandre Viau — Thu, 21 Sep 2023 15:21:48 +0000

Bombarded with multiple alerts coming from multiple disconnected services, security analysts continue to struggle with alert fatigue. While they need context about threats facing their organizations, many also find identifying the right context challenging.

Today, companies expect security analysts to be experts in everything from the technical to the criminal underground. In reality, this just isn’t possible. However, large language models (LLMs) excel at summarizing large quantities of data, offering security teams a starting point for their analyses.

Flare uses LLMs to help analysts get the insights and answers they need quickly so that they can filter out false positives and focus on what really matters.

Using LLMs to Provide Context

LLMs can help separate out important context. Typically we see two different use cases: non-technical and technical.

Non-Technical Context from LLMs

From a non-technical point of view, LLMs adapt well to given slang language. They understand the context and quickly summarize information, eliminating the need to do Google searches.

First, criminal underground chatter uses slang that has a different meaning within their community when compared to the technical community.

For example, they often use the term “logs,” referring to stolen usernames and passwords. Technical professionals usually recognize this term as the digital record of activity happening in their environment. With the prompt, LLMs can “translate” this for you.

Second, LLMs can help you understand what an application does. For example, when threat actors post stolen credentials for sale, they usually name the application. By explaining the application, LLM tools make it easier to determine whether the stolen credentials pose a risk to your organization’s security posture.

Technical Context from LLMs

At a technical level, ChatGPT does an excellent job of helping analysts better identify real, exploitable risks to their environments.

For example, when Flare identifies a GitHub match, the LLM can look at the code and understand whether the mention indicates a risk or not. When developers use a base template for an app rather than starting from scratch, they often make a copy and rename it for their company before they start working. Sometimes, these files may have a hardcoded password. However, this public facing hardcoded password poses little risk to the company until the developer starts modifying the code to build the company-specific application.

When Flare detects the company name in GitHub, the LLM provides context around whether the match poses little risk because it was in a default config file or could indicate a problem because the developer made a modification.

Limitations of LLMs

While LLMs provide various benefits, they also come with some limitations. LLMs analyze unstructured data which poses difficulties when writing prompts.

Unstructured Data

When inputting a query, the LLM has a hard time deciphering the difference between the question being asked and the data being supplied. For example, if you’re providing the text of a message and asking if it was written by a specific threat group, the LLM gets confused. It can often focus on the threat group’s name or a username in the prompt rather than analyzing the message’s text that you want to know about.

Input Size

LLMs can limit the amount of data that it can summarize so choosing what information the prompt includes is critical.

Although ChatGPT’s context window simulates a conversation to look human, the LLM doesn’t “remember” the beginning of conversations. If you engage in a long conversation, then it won’t be able to answer appropriately because it may not be accessing the original information, such as the threat actor's name.

To get the most accurate actor profile possible, you need to choose the inputs carefully. Ideally, when an actor is active on the criminal underground and the clear web, you want to take a little bit of both. You need to combine some of the:

Oldest criminal underground activity
Recent criminal underground activity
Oldest clear web activity
Recent clear web activity

With the right inputs, the model can fill the gaps, giving you a good high level view of what the threat actor does.

Source Code

LLM models use tokenization that transforms texts into numbers which often means that ChatGPT can analyze less code in a given input than it can text. Consider the following:

CHAT GPT
chat GPT

While the human eye and mind reads these as the same two phrases, the LLM model transforms following data point into a separate number:

chat
CHAT
G
P
T

What people think is two pieces of data, the LLM model views it as five.

When communicating code with ChatGPT, you have a smaller token budget than you do with text, meaning that you have to be more careful when inputting queries so that you don’t waste energy computing information that doesn’t matter.

In this case, you want to look for the interesting parts of the source code and only send those. Some examples might be inputting:

The metadata for the part of a file where your company’s name is mentioned
Specific project name, location, and developer

Lessons Learned: Engineering Prompts

When dealing with token budgets, engineering prompts become incredibly important. Unfortunately, no clear answer around best technique exists. The process requires you to test and iterate the prompt. Some prompt improvements more than doubled the output’s value.

LLMs can assume that all information provided at input is true or factual. For example, a prompt might ask a question about whether your company’s data was part of a specific data breach. The LLM will assume that the corporate data was part of the breach rather than researching the breach to look for the corporate data.

Future of LLMs in Cybersecurity

A fundamental problem in cybersecurity is the communication gap across different people in the company. LLMs are powerful for communication between different audiences, especially when looking at how teams can use them for reporting. LLMs empower less experience security team members by helping them understand context so that they know how to efficiently escalate alerts. Additionally, CISOs and others interacting with business leadership can use LLMs to explain technical bugs or data breach information in a way that addresses that audience’s needs.

Connect services across Kubernetes clusters using Teleproxy

Alexandre Viau — Thu, 21 Jul 2022 20:36:00 +0000

Teleproxy is a shell script that lets you quickly replace a Kubernetes deployment by a single pod that forwards incoming traffic to another pod running in a destination Kubernetes cluster.

The tool is based on telepresence. It is used at Flare Systems to keep our development setup light and still be able to quickly connect our test apps to a more realistic “staging” environment.

See the code at https://github.com/flared/teleproxy.

Ideal for minimal Minikube setups

Most of Flare Systems’ development setup is based around Minikube, a tool that lets you run Kubernetes locally as a single-node cluster.

While Minikube is great, we quickly ran into performance issues. Devs don’t necessarily have the resources to run all the services they need to test the software component they are working on, or maybe they’d rather have more than 30 minutes of battery life! They may also want to interface with a database that contains more data than the one that we ship in the local development environment.

It would be great if there was a tool that allowed you to quickly swap the database that runs locally inside Minikube with a proxy that points to a database running in another cluster. This would allow for all services running in Minikube to instantly connect with another database with little to no configuration changes. This is exactly what teleproxy allows you to do.

Using teleproxy to swap a kubernetes deployment with a proxy

Say you have local deployment called someservice with pods listening to port 8080 running in your local cluster and you want to replace it with a proxy to another deployment running in a destination cluster, you would run the following command:

tele-proxy \
    --source_context=minikube \
    --source_deployment=someservice \
    --source_port=8080 \
    --target_context=staging \
    --target_pod=someservice-77697866c6-vsk59 \
    --target_port=8080

How it works

Teleproxy is based on telepresence. All it does is it runs kubectl port-forward in telepresence’s replacement pod. If you don’t already know how telepresence works, the following deployment diagram should help. It follows traffic from a client pod, which uses the service that we are replacing, to the target pod, which is an equivalent pod running inside another cluster.

The traffic originates from the client, it probably targets someservice using the deployment's Kubernetes service.
The traffic is received by telepresence’s incluster container. Telepresence has scaled down the someservice deployment and has replaced the pods by this single incluster proxy. It forwards any incoming traffic to the telepresence local pod which is running outside of the cluster.
The traffic is received by telepresence’s local container, which forwards it to the teleproxy container.
The traffic is received by teleproxy and is forwarded to the destination pod in Cluster B trough kubectl port-forward. This container is able to run a port-forward to your destination cluster because it mounts your local kubectl config, some specific environment variable and contains common tools for authenticating against a kubernetes cluster such as the AWS and Google Cloud CLIs.

Debugging Teleproxy

If you start from a working telepresence setup, the only complexity that is added by teleproxy is that the teleproxy container must be able to connect to your target cluster. Depending on how you regularly connect to that cluster, you may need to mount configuration files or add environment variables to the teleproxy container.

We have configured teleproxy for our own use and have gotten it working with both GKE and AWS EKS, this required:

mounting ~/.aws , ~/.kube
Installing the AWS CLI and Google Cloud CLI
Setting up compat symlinks for OSX users.

There is probably more to do, and we are willing to merge anything that makes sense.

Appendix

Telepresence: https://www.telepresence.io/discussion/overview
Open Source @ Flare Systems: https://flared.github.io/
Teleproxy: https://github.com/Flared/teleproxy