And hello everyone.
Today we will end today with a discussion about large language models.
So basically we will be talking about how you can leverage large language models into your workflow even if we're talking about security here.
How we will approach this presentation is by doing the last in the middle technique.
What is the last in the middle technique?
Well, while I was researching for large language models I stumbled upon a paper which was actually analyzing context for large language models.
What do I mean by context?
You know that there are a lot of variants of large language models and each one of them has like a limit on the prompt size.
And right now like the biggest limit is 120,000 tokens which will translate to roughly 40,000 words.
And some researchers were asking, okay, so you have like these huge prompts.
Will all the information in the prompts be used equally?
And they answer it with no.
So basically the information that the large language model sees first and sees last will be more impactful in the answer.
So if you have some information in the middle of your prompt it will not be that relevant.
And you can think of it as an analogy on how us humans are operating.
I mean if you're in a meeting the meeting starts you're paying attention and as the meeting goes you start losing attention and because the meeting ends you need to pay attention again.
So the presentation will be like a bit of more focused on applications.
Then we're going to delve into the details because details are a bit not that interesting because in a conference the idea matters most.
And then Octavian will also show you some other cool applications at the end when you will be paying attention again.
Okay, so a bit of context.
How in security did we reach the LLMs?
How did we think of using them?
Well it all started with threat intelligence and most likely with threat reports.
So we had like a lot of threat reports like 2, 3, 4, 5, 10 a day and the reports are rather lengthy so we had to sort of ways to analyze them on like automatically analyze them.
And first ideas were like based on old machine learning techniques but while I was playing with those old machine learning techniques I was starting to experiment with something new with actually using large language models feeding the report into the large language models and see what the model will have to say about it.
And I was pretty impressed.
So as a POC we have a slack bot because everybody loves slack and everybody interacts with slack in which I actually feed a threat intelligence report.
The idea is that this report has like 10 pages so it's long.
So what if you want to quickly spot the attack pattern described in the threat report?
You can simply ask the large language model to describe it and it will give you a rather lengthy response and it has like all the details included in the response and you can also interact with that response and say okay not that big make it shorter and it will give you a shorter version.
Then you can actually take the summary of the report.
You can expand on some techniques that are presented in the report and so on and so forth.
So it worked pretty well.
And because this worked pretty well we are starting to wonder about how about not one single report.
How about tons of reports?
How about tons of files?
So here there is a technique that is now research and used.
It's called retrieval augmented generation.
So basically you can make this work with not just one file but with many other files.
So here in the right side you can see that I've asked like describe the attack trends in the last six months.
So how will the LLM know about the attack trends in the last six months?
Well basically we hooked a database that contains CrowdStrike reports and it basically knew how to search through those reports and provide an answer.
The same thing in the middle and in the right we have like another database that the large language model connects to and answers based on that.
And we can see that if you're like skeptical about the answer you can tune the prompt for the model to provide source URLs or even the source text.
So now we're going to see how I did that pretty fast and then I'm going to explain it more in detail.
So we're going to go through a short tutorial and actually to set up a Slack bot in a Slack channel called the Cyber Samurai.
So the first step in having a Slack bot in a Slack channel is to have a Slack channel.
So we have our bot.
The next thing is we need to actually create the instructions for the bot.
We're going to see that our solution actually supports multiple large language models and these large language models are sensitive about the way you present the information.
So in order to not stop the service and reload it again we're going to have the service hooked to a GitHub repository in which you simply paste in the instructions.
So we have here you are a samurai from Edo period.
You recently learned the ways of cyber security and this is the important part right here.
This is where our documents will be injected into the prompts and then we have the query.
So this is like the third step and now we just need to link the channel to our prompt.
With just three lines of code which are in a configuration file.
And now let's see if we did something.
So we have the question, tell me about a ransomware named Cactus.
And we tried this question on ChatGPT.
So ChatGPT said that it doesn't know anything about that ransomware.
And then we asked our samurai.
We actually typed the question in our Slack channel.
And then our samurai started to respond.
Ah, the Cactus, a formidable foe in the realm of cyber warfare.
And then it tells you about the ransomware in a samurai style.
So this is not that recommended because if you actually instructed to talk like a samurai it will most likely get some hallucinations from now and then.
But the idea is that it comprises the information and it actually tells you a lot about the ransomware.
And also a notable battle, a Canada-based insurance brokerage fell victim to the Cactus.
And the adversary was ruthless.
So just in like two minutes you can have your own customized agent that runs in a Slack channel.
Not only a Slack channel, we will see.
That connects to your information.
It's important to note that here Sherlock is connected to the CrowdStrike report.
So this is where the information about the ransomware named Cactus came from.
Now we're going to talk a bit more about the details.
Okay, so basically you have your entry point which is Slack, Teams, or our API which connects to Sherlock.
So you give it a request and you'll get an answer.
So we have multiple requests.
Sherlock returns answers.
And it's important to note here that we're in different channels.
So up top is the direct interaction.
You simply talk to the bot.
And here we have channel A and channel B.
And in channel A, Sherlock says that it's an AI system developed by ACC that can provide assistance and answer questions in the realm of cybersecurity.
And here it says that it can actually answer questions related to Adobe products.
So totally different personas.
So how did we accomplish this?
It's how I said earlier by using the Git repo.
So it's basically the request contains the prompt that it needs.
And it will simply look into our Git repo and select that prompt on the fly.
So you don't need to restart your service or something.
So we can see here that the query in our actual request is who are you and then you can select the prompt.
Another cool thing nowadays that a lot of LLMs are emerging and we know that GPT-4 is the undisputed king as of right now.
But LLAMA is an open source model.
And Mistral is actually an open source model that proves that you don't actually need that much computation in order to get a good LLM.
So Mistral with only 7 billion parameters can beat LLAMA2 with 30 billion parameters on some benchmarks.
You have Bardai, Grok from X, and Falcon which is also open source I think.
And the cool stuff is that Sherlock can interact with multiple deployments.
So it's basically you have your deployment on a machine and Sherlock will serve the request to that deployment with the prompt and with the necessary adjustments to the prompt.
You can specify the deployments in a configuration file and then select them in the API.
And now let's see about how can we leverage our knowledge basis.
So here I asked Sherlock what actor would use that command.
And Sherlock said that it is difficult to determine.
However, and he tried to give an answer.
It's a good answer but we can get it to be even better.
So right now we have our knowledge base.
So the knowledge base is actually a vectorized store in which you upload files and you index them in different buckets.
And this knowledge base will be used to augment our prompts and then we will feed our prompts into the large language models and then we get the answer.
So now it correctly identified prophet spider as an actor that would use that command in their attack chain.
Now it seems simple and the idea is that you can do a lot of cool stuff with retrieval augmented generation.
But there are a lot of, let's say, corner cases that you will stumble upon.
So basically when you ingest a lot of data you need to segment the files so that you don't actually load a lot of unnecessary data into the prompt.
So how can you actually identify the good data for you?
We're using keyword search.
So basically you have your query.
You use that query to extract based on the words, the top K documents.
And we also have semantic similarity which means that by using open search models we compare the similarity between the query and different parts of the files and we extract them to then enrich the prompt.
Also we will see in another corner case that we also need to enrich the documents not only retrieve them correctly.
So this is the example I'm talking about.
The question is describe the attack trends in January.
So let's see how Sherlock will actually try to solve this.
It will try to extract some chunks from the knowledge base that contains trends, January, describe, attack, and it will get a lot of matches and then it will rank those matches and get the top K matches.
And at the same time it will try to match the similarity, the meaning of the question with the meaning of the things in the knowledge base.
So like the meaning of the question like describing, attacking, or something like months and it will extract those parts.
But it's not enough.
Why?
Because it will extract all of the documents that have January in them, it will extract all of the documents that are indicating to a temporal context, and in the end it will return something that's not that valuable.
So how can you overcome this?
It's basically you will add an extra step.
Based on the query, you first extract some filters, which then will be applied to the knowledge base, which after that you will actually extract the relevant documents.
So basically you extract, you use the large language model to extract that today is... whatever date is today, I'm not quite sure.
And then it will actually, you see that it inferred like greater than 1st of January, lesser than 31st of January.
And these filters will be applied on the knowledge base and then we will shrink our knowledge, our space of search.
And then when the first part with the keyword and semantic similarity search will come into play, it will get better results.
Okay, it's quite nice because this journey of developing the tools, because basically Sherlock is a collection of tools that allows you to actually have your thoughts in like blazingly fast time, inspired a lot of people from our team.
And while we're building the infrastructure for Sherlock, other people are already consuming that infrastructure.
And I will now let Octavian to talk to you about some cool stuff that were developed in parallel through our infrastructure.
So I'm going to talk about a few SOG-related use cases for Sherlock.
In the context of alert triage, analysts usually face a significant amount of noise.
And while traditional log curation methods can reduce this noise, they demand frequent updates and must adapt to the continuous addition of new log sources.
As you can see on the right side, we have a bunch of command lines that might look messy and potentially hard to understand for analysts.
And that's where LLMs come in handy.
During the development, we realized that LLMs require a well-structured prompt to function effectively.
And with this in mind, we designed this specific prompt, which now is an integral part of our source solution.
We'll demonstrate that shortly.
Other types of prompts of design are the one for pulling IOCs, reverse engineering code, email drafter, and so on.
This is a screen from Splunk SOAR, and we have an alert with a command line.
And due to alert fatigue, one might be tempted to quickly check what it appears to be, an IP address, and lose valuable time during the investigation, just to realize that it's not a valid IP address.
Our approach with Sherlock was to resolve these kinds of cases where such mistakes are done.
And the entire command line is fully explained, so that the analysts will be able to make more informed decisions and to eliminate at least parts of their biases.
The conclusion from the command line we've seen earlier, as you can see, is not very conclusive.
And that's actually good, because it presents both sides of the story.
We've also tried to enhance the user interaction with Sherlock, and we've introduced straightforward browser extension, where analysts can choose from a predefined list of default prompts, or they can input their own custom prompt.
And as you can see, messy and very hard to understand command lines are sent to Sherlock, and they are translated into more user-friendly and easily digestible texts that analysts can use during their investigations.
Now, speaking of data ingestions, we have a series of agents that collect data and send it to our knowledge base.
One of them is an HTTP scraper, which is able to collect data from any Adobe web page and send it to our knowledge base.
And another one is Jenky's pipeline, which pulls cross-track reports, extracts those IOCs, and again, to our knowledge base.
And this concludes our presentation.
So, thank you, guys.
And if you have any questions...
I'm just gonna pick up one of the mics quickly here.
Keep your hand up, please.
Over there.
Hi, guys.
Really nice presentation.
Congrats.
I have a couple of questions.
First of all, would Sherlock be able to do a summary of a discussion inside of a Slack channel, like, let's say, a security discussion or incident response discussion?
And the second question is, do you think you can use Sherlock, let's say, to train it on your alerts and responses for alerts and try to offer guidance or false positives, newly generated alerts?
Okay.
So, for the first question, the answer is yes, it can actually do that.
I mean, it cannot right now, but it can be easily implemented.
And for the second question, it's a good question because you mentioned about training on data, right?
So, retrieval-augmented generation does not rely on training, and it's an entire discussion about fine-tuning a large language model and actually using this technique.
And in most cases, this technique is better because you actually can onboard new data to your work stream whenever you want.
So, how can you actually fine-tune the model without fine-tuning it?
You can have a knowledge base with a lot of examples, and then when a query comes in, it will extract those examples and it will use them as examples for the answer that it will give you.
So, pretty much, yes, it can be done.
Okay, thank you.
We have another question here.
Yes, thank you.
Hello, guys.
So, thanks a lot for the talk.
It was really interesting.
I want to ask you kind of like a technical question regarding the other side of the fence.
So, basically, I'm working for a threat intelligence company for Kaspersky.
We are the ones writing threat intelligence reports.
My question for you is, what would be the formats that you would like to see when threat intelligence vendors are providing reports to you?
Because, for example, at least us, we are providing in PDF, and we're giving some SNORT rules and some YARA rules, but PDF is the base here.
What would be, in your perspective, what would be a good format, maybe a computer-readable format that you can ingest from threat intelligence teams in order to better integrate with your LLM?
Yes, so, from our experiments, LLMs are very powerful with text.
So , as long as you have text in some format, they will work, but it's always better to have that format in a natural way.
So, I mean, you can have PDFs, you can have Word, you can have a lot of things.
With Excel, it's a bit more difficult because there is a structure there that it needs to understand, but it still works.
So, to answer your questions, your question is like, as you do right now, it works.
So, the way you provide the reports right now, it works.
Okay, so, it wouldn't make it easier for you if there's like a report?
Yeah, I think that would make it easier is that when you actually ingest these reports, you need to split them because you don't want to extract the entire report in your prompt.
Only if you want to, if you have like the 120k context window, but the idea is that to not have the information that's fragmented.
So, in page one, to say something and then try to elaborate on that on page three or something like that.
Like the, let's say, spatial locality of data to be like restricted as possible in your... Okay, makes sense.
Yeah, thank you.
Thank you.