I think we are good to go.
Okay.
So, could you close the doors?
Please close the doors.
So, where are time?
Yeah.
Please welcome Bucklocks.
Thanks.
Hi, everyone.
I'm Federico Foskini.
I'm the third detection team leader at Sertigo.
In addition to my role there, I'm also a Google signer of code mentor for the
One in the organization.
I will tell you more about that later.
And also, lecturers in the master of cyber security at the University of
Bologna.
I'm Lorena, a third detection engineer at Sertigo.
Completing a master degree in computer science.
I'm also the creator behind the Federico's idea.
And the principal maintainer of Baphologs.
An open source project we'll talk about later.
And now we'll start explaining the origin behind its birth.
So, in Sertigo, we have a main product.
It's a managed security service portal.
All the detection and services we implement are either made in house by ourselves or based an open source software.
So, we are deeply committed in contributing to the open source community.
And we wanted to develop a new threat detection tool, but we didn't know the scope yet.
So, we set ourselves a specific criteria.
We wanted to build something that solves a common point for security teams and just not an
niche problem.
It has to fill a genuine gap in the security landscape.
And also, it has to be something that could be manageable by a small team.
In fact, most of the development has been done by Lorena, single end.
So, hi, how we identify the right focus for our tool.
We took two approaches here.
The first one is reviewing and evaluating existing commercial products.
To see if they offer innovative solution lacking in open source alternatives.
And the second we review, we are reviewing security incident.
We manage to see if we can identify common patterns that could be better detected.
So, let's talk about project evaluation.
These are one of the commercial products we want to evaluate.
We can do the evaluation manually by installing the product ourselves and run all the tests.
That will be extremely time consuming and also very expensive.
So, we look at reports made by organization that are specialized in productive evaluation and classification,
like Mitre with attack framework first, I DC Gardner.
And what did we find?
Interestingly, we found out that every vendor claims to be a leader and also claims perfect detection rate.
That's looked to me that they are writing their own rule and awarding them as their prizes.
We know that doesn't reflect the reality of cybersecurity.
As Wendy Nafer pointed out in an amazing presentation, she did a couple of weeks ago.
The same problem we faced 20 years ago, persist and also are amplified by increased software complexity,
ripple effect of breaches, monetization and data.
So, we know that could be room for improvement in detection.
When our first approach doesn't yield and result, we start analyzing the kill chain of attacks we manage to see if we can identify common attack patterns.
In the last year, we managed 10 major compromises and the defining we are striking 7 out of 10 of these breaches.
Involved compromises credential obtained through data leaks.
Two were through fishing campaigns, and only one was an actual attack where ACVE was used to reduce the key space to conduct a force attack.
Past in the last year, we see some key patterns like VPN, remote test tool for persistence, lateral movement, that encryption crypto currency mining.
What we learned from here, basically, should think.
The first thing is our customers spend a lot of money in very advanced security product,
still get a bridge through a legitimate login with a stolen credential.
And also, this given site, and we learned that we need to focus on the initial access where the most common attack vector I was.
And that's basically how buffaloes was born.
Buffalo is in an open source solution for authentication protection, designed to detect and alert the most common tactics used by attackers.
I let Lorena continue, and she will delve deeper into buffaloes internals.
First of all, it's important to underline that the buffaloes project consists in the detection of the anomalous login.
Indeed, the first phase based on the login data collection.
It's an ingestion phase where we use the file bit and elastic search, but they are not required.
So in let's recap all the process.
The first phase, the ingestion phase, in addition to the collection of data.
Geolocation information is enriched, and the field normalization occurs.
After that, the logins data are processed and analyzed by the detection logic.
And just the interesting logins are saved into the buffalo zone database.
Of course, with the relative user send alerts.
These data in the database are cleared for the creation of user inventory for create a web interface and to send alerts to the alert to watch her module.
The installation process is very easy dealing with containerized Docker application, so it's just required to clone the repository.
Run the application container, and if you'd like to interact with the Django admin panel, you have to create a super user.
The first version of the web interface is minimal.
I don't like front end, I really don't like front end.
But there are some interesting graphics, for example.
We have a graphics about the users that triggered the alerts divided by the risk score.
Then we have the alert split up by trigger date time, a table with the alert summarization, and a map in order to emphasize the location information of the logins that triggered the alert.
But now let's deep into the really core of buffaloes.
More in detail, the anomalous logins reported by buffaloes include different types of anomalies, such as related to the appliances used, some users information, or familiar properties in country where the login occur.
Some of them are labeled with the working progress, but they are just running internally and have to be merged into the public repo.
Let's clarify some of the detection with an example.
So if we have a first login from Milan at three, and then after an hour from Rome, this will be considered an impossible travel, because the relationship space time, it's not exceeded the threshold metrics that are considered feasible for this distance of course.
Supposing the following logins is done at 1250 from Vienna, this is not an impossible travel, but it's considered a new country alert.
And then supposing a new login from Austria happens 30 days later, this will trigger the not typical controller.
The logins utilizes different user agents, and some IPs are considered anonymous, their relative new device and anonymous IP login alerts are triggered.
The detection to highlight the so-called state accounts, that is an integration of the user inventory that would consist in querying the APIs of the internal authentication service used by a company in order to compare the login information with the logins captured by buffaloes to send unfamiliar vulnerabilities.
For example, if we have on the left table, a user, John Doe, a user, John Doe that has logged and is active for the internal authentication service used in the company, but for buffaloes he has never logged in, this could be a possible vulnerability for the system.
And also the Mark Turner account that has not logged for a while.
Once explained the detection types, let's take an overview about the detection logic itself.
Since the different input sources are accepted, we have to normalize the data and mapping them into a predefined schema.
The initial in just the process is recap here, and we have all events cleared every 30 minutes, and just the login events are saved and processed by the detection logic.
These logs are normalized in the schema shown before and grouped by users.
All these logins are then processed by the detection engine and just the anomalous one are sent as alerts.
This phase of ingestion is very crucial because we deal with a really huge amount of data.
Indeed, the power of this project is that since the beginning it has developed using real logs, gathered from both web applications and cloud services.
Testing the detection on about 500,000 real data allowed us to improve the alerting logic step by step.
In addition, the final version of buffaloes is running on the search code detection platform, analyzing the data of more than 30 customers for a total of about 300,000 logins per hour from different sources.
On the other end, these high amount of real data has brought out some critical aspects.
First of all, we saw that a user could use different types of devices, for example, logged in from the PC and from this smartphone.
This will change rapidly the user agents, of course, but if we consider also that as smartphone could log in using the mobile data or so the IP is changing frequently.
If a user also uses the company applications with different networks, for example, with VPN, we saw a proxy network and from not proxy network, this will change the IP uses.
So what's the problem, of course, so many alerts occur and the user profile creation was made really impossible.
But we found a troubleshooting and we developed a personalizable filter page where in this config panel, we can create custom filters about the users.
For example, our location devices and alerts itself.
Moreover, we gave the possibility to change also the detection metrics and this gives a sort of bring your own detection characteristics to buffaloes.
And this is a nice feature because the most detection services don't provide the changes of these parameters.
Another problem we faced is the possibility that different location providers give us for the same different locations.
So this of course could give us the wrong log in information.
And we identified the maximum as the most accurate provider.
Thanks. Speaking about the future.
Basically, we want to add a lot of additional sources, maybe reading logs from Postgreeds database.
It's my SQL gray log and adding new alert notification and sync feature.
But I think our primary focus will be implementing automatic user blocking, that's something that identity provider already supports.
And when triggered, these functionalities will automatically suspend user accounts when as suspicious activities detected.
And also allowing the user themselves to unlock his account, maybe through a password reset or a multi-factor authentication confirmation.
This will greatly reduce alert fatigue and also streamline security remediation.
The last point, actually, is there because that it told me is mandatory, I think, a little glimpse during presentations.
I really don't know what to do with these technologies, but maybe you do, speaking with that.
We are participating in the Google Summer of Code. For those unfamiliar, this is a project where students can contribute to open source projects and during their summer break and get paid by Google.
So I think it's a great occasion to contribute to buffaloes.
If you are interested, check out our repository because as soon as Google will confirm our participation.
We will be adding all the details there.
And that's all. Thanks everybody.
Thank you.
Yeah.
Sorry.
Yeah. The question is if it's possible to ingest on logs in the system.
And yes, but you need to use this data schema.
If your logs contains these fields, buffaloes automatically will read them.
Yeah.
Okay.
Okay. The question was if we can also ingest custom detection.
Okay. So like additional information about the logins.
No, actually, it is not supported. I think it's something that's fit better like a CM or something else.
Because with buffaloes, we really want to implement only the detection part of it.
And not the parsing events from other sources.
Apart from this information, we need to do our detection.
Yes.
Yeah.
The question is why we create buffaloes when other product supports the same feature essentially.
Basically, two things. The first one is most of these product are closed source.
And the second one, the most important one is with buffaloes.
We have control of the detection ourselves. We are made the algorithm ourselves.
So we can change it more easily and also adding new new new stuff.
Because what was limiting us before buffaloes were when we received alerts from other identity provider like Azure.
And we actually didn't know how the detection was implemented.
So we gave, we read an alert like impossible travel, but we didn't know how it was calculated.
And on what events and so on.
Okay.
No, it's, it's all on buffaloes because we wanted to split the logic from the weekend.
So in, we, in this example, last search was used only for events.
All the logic and detection are inside the jungle in Python basically.
Okay.
Yeah.
Is alert fatigue because most of the, this type of detection cannot be determined.
If we see or not without asking the users because we have a lot of of false positives when the users travel abroad.
And basically what we are doing right now is sending the alert directly to the user itself.
So it can confirm or not, but and that's why I really wanted to implement the automatic user blocking feature to avoid the amount of other alerts.
We are receiving now basically.
Not really because.
No, because we don't save all the logs data of the customers into the buffalo database.
There we save just the last logins and update them step by step.
So we reduce a lot of data saved.
Yes.
Yeah.
The question was if we have planned to add the real time detection.
Yeah.
Actually, that's other to do with our architecture right now.
But also you have to keep in mind that some providers like Azure.
Generates log with with a big delay up to 24 hours.
So you do not do not have the guarantee even if you are analyzing the events you are receiving.
In real time that your detection with really really real time.
Yeah.
I think we are out of time.
Yeah.
Thanks.
Yeah.
Thank you.