Outstanding. Apologies for that. So, my name is Aaron Seto. I am the Director of Learning at CoreLite.
And today I'm going to be talking a little bit about the Zeek open source project in the light of OpenSoC.
So, I've actually been part of the OpenSoC team for several years.
Very excited to kind of talk about how these two projects are going to work together.
Today's presentation was actually going to be a joint presentation with Amber, who is our Zeek Community Director.
She had some unforeseen circumstances came up, so I'll be talking a little bit about the community piece,
but I'll try and do it justice to her content.
To kind of talk a little bit about... hold on, let me get my... I see that is going to be...
I do not blame Discord right now. It just had the rug pulled out from under it.
So, let me switch over to this.
So, I'm going to talk a little bit about Zeek. What is Zeek?
It's an open source framework that is used for network security monitoring, basically looking at network traffic.
And you might have heard of Zeek as BRO.
So, this was back in 1995. BRO started at Lawrence Berkeley National Labs.
And there were a number of people who were looking into this problem space,
and were thinking not even in a security context, but just looking at network traffic at large.
And the name BRO really was kind of a nod to Big Brother, being like, this has a lot of surveillance potential,
but it also has a lot of network security potential, which is obviously what we'll be focusing on today.
But if you've heard of BRO or if you've heard of Zeek, it was probably as part of a research center university government,
even potentially for like network forensics and network operations.
There's actually some vendors, though I mentioned I'm employed by Corlite.
There are a number of vendors who actually have Zeek integrated in with their platform and use it.
So, if you've heard of it before, that's probably why.
Zeek itself is actually very customizable, very extensible.
It's really kind of its own language.
And there's a lot that you can do with Zeek in terms of just having scripts and plugins and protocol analyzers
and kind of these components that work together to analyze your network traffic.
So, there's the Zeek package manager.
If you go to packages.zeek.org, you can see all of these packages that the community has contributed.
But you also, because it's open source, you can write your own.
And so, there's actually a try.zeek.org environment where you can play around with that.
And I'm not going to dive into that too much right now.
I just want you to know that it's out there.
So, what is the data?
Like, the Zeek data is really where the power is.
And I want to talk about what that looks like.
So, I'm going to use three examples here, three logs to kind of start that conversation.
On the left is the con log.
So, that's the connection log.
If you've ever seen NetFlow and it's got like IP addresses, ports, protocols, timestamps,
like all this really high-level information, that's basically the con log.
Every single connection will appear in the con log.
But then there's these other logs that are more protocol-specific.
So, let's say I have HTTP data.
Like, I have a web browser talking to a web server.
I'm going to see all of the metadata associated with that connection.
So, things like what was the user agent string that was sent?
What's the URI that was requested if you're talking about the client side?
From the server side, like what was the MIME type that was returned?
How many bytes? What was the status code?
All of those things we see in our HTTP log.
Similarly, if we're talking about other protocols, let's say like DNS,
I can see the DNS, like the client and the server.
I can also see the queries and the answers, the responses,
which is surprisingly difficult to dig into sometimes.
We'll talk about that more in a second.
Now, realistically, there are only a few logs that you're really focused on
in a given environment, in a given exercise, and frankly, even in OpenSoft.
But, there are probably pushing four dozen logs in total now
in the ZEKE OpenSource project.
So, there's a log for pretty much any protocol you can think of,
and all that metadata, that rich metadata from that protocol,
is stored in that log for whatever purpose that you might need.
I've got a couple links down at the bottom, too.
CoreLite has a little PDF cheat sheet. I'll have that link for you in a second, too.
And the ZEKE OpenSource project has really good detailed documentation
about logs and even some things that didn't make the cheat sheet.
That's actually where I stole these graphics from, was from the CoreLite cheat sheet,
because it's a little more colorful.
So, to really talk about how we use ZEKE,
let me start off by kind of comparing a little bit.
So, we need to see if things are actually fine, or if maybe things are fine,
or if things are actually not true,
then we get something from tools like Wireshark and gpdump.
Or, in the middle, we have intrusion detection systems,
intrusion prevention systems.
So, things like Snort and Suricata,
things that we'll find as we kind of work our way through
just kind of looking at this kind of signature-based detection.
And then, on the far right, we have NetFlow.
We have the IP addresses, ports, protocols, timestamps,
that kind of high-level information.
These are three very common tools,
which we'll see as you're kind of getting familiar,
as you're probably already familiar with.
But, let's use those to kind of compare ZEKE.
To start off with, ZEKE is really fundamentally different from something like NetFlow.
Well, it's fundamentally different from all of these, but let's start with NetFlow.
So, NetFlow is giving us just that IP address, port, protocol, timestamp,
just that generic info,
versus something like ZEKE is going to be able to understand protocols at a much deeper level.
So, it understands how something like HTTP works,
and it can pull out all that metadata.
It can even see things like files being sent over HTTP and extract those files out.
So, we're not saving everything, we're saving the most useful tidbits.
And really, when you're thinking of ZEKE,
I don't want to talk about how it compares to some of these tools.
I want to say, like, throw away your IDS, throw away NetFlow.
What should be useful?
Deploy ZEKE in parallel with these tools.
And especially if you have something like full packet capture,
then you can go ahead and use ZEKE to help find
where the most interesting pieces of that full packet capture, that data resides.
Now, comparing ZEKE to an IDS is something that's very commonly done.
And I want to take just a second to talk to that,
because ZEKE isn't here to say what's good or bad, or what's right or wrong.
It's here to say, this is what's happening in the network right now.
So if something goes south, it's because I need to respond to that,
or at least I need to investigate it to look at it.
But ZEKE is here logging everything that's going on
and giving us the control to say, is this good or is this bad?
Now, as I mentioned before, ZEKE is very expandable, very extensible.
And so there's a lot of things that we can add on to ZEKE.
We can kind of do things like, hey, if you see these kinds of anomalies, let me know.
Because ZEKE understands protocols at such a low level,
it can do things like say, hey, this looks like protocol abuse.
This looks like a situation because I totally understand how this protocol should work.
And this is not conforming to that standard.
I'm going to go ahead and write a notice log.
I'm going to go ahead and write something to the weird log.
And we'll talk about some of those logs a little bit more in a second.
But there's a lot of things that we can do with this.
So when I'm talking about ZEKE data,
what I'm really talking about is the representation of network traffic,
of what you're seeing on your network as it's represented in ZEKE data.
Now, there's a couple ways you can get those logs out.
You can look at the raw ZEKE logs.
And we'll kind of see a little bit of that today.
But as you normally use in an enterprise, and as you'll use in OpenSOC,
that data is being forwarded to a SIEM where you can interact with that
and get the context of all the other host-based data
and everything else that's coming into that SIEM environment.
So in case you haven't guessed already, our SIEM of choice for OpenSOC,
if you were watching the workshop earlier, is Greylog.
And so we'll talk about what this looks like in Greylog.
But one of the things that is... before we jump into that,
I want to talk about how we kind of associate these logs with each other.
So remember I said we have a CON log and an HTTP log.
And so every connection that comes in, I'll see in my CON log,
but every time there's some HTTP data,
HTTP application layer protocol identified in this connection,
there will be an HTTP log for that connection that has all that relevant metadata.
Now, the question becomes, how do I kind of pivot?
I see something in my CON log, and I know there's HTTP in there.
How do I go find the matching thing in my HTTP log?
So the way you're going to do that is with what's called the UID,
or the connection unique ID.
And that's something that every time there's a mention of this connection,
it's going to appear in any one of these logs.
So if I have a connection, let's say, that uses HTTP,
and let's say it transfers a file.
Well, then I'm going to see that same UID in my CON log, in my HTTP log,
in my files log, and each one of those logs is going to give me the information about that file transfer.
On the topic of file transfers, there's another type of unique ID called the file unique ID.
And similarly, if I kind of want to pivot around and investigate a file that's happening,
or that I'm interested in, then I can use that file unique ID and search through logs
and see what connections are associated with that unique ID.
So, all right, I've done a lot of the explanation.
I want to dive into one pretty thorough use case.
And I want to do this for two reasons.
One, I want to get you in the mindset of how an incident responder thinks.
And for some of us, that's not a stretch.
And for some of us, that might be a little new.
But the second thing I want to do is I want to show you how you would use just a ZEKE data
to work through a particular incident.
And so let's say I'm fresh out of college or fresh out of another career field I'm pivoting.
And I just joined this team.
I'm a SOC analyst. I'm entry level.
And as is tradition, I am awarded the honor of the night shift.
And I'm sitting here, and I'm watching alerts roll in.
And it's my job to kind of triage these alerts.
So I'm trying to figure out when something comes in, do I have like a playbook or procedure,
something that I can fall back to, to say I know how to handle this, we've seen this before,
or I have something in my playbook that I know how to resolve this myself.
Is it maybe instead something that I can dismiss?
I can say, well, this is a false positive, or this is not actionable.
Okay, somebody's port scanning. Doesn't matter. I can't really do anything about it.
Or in the third case, do I need to escalate this?
Do I need to bring this to someone, a senior member of our team,
who can then spend a little bit more time looking at this, or maybe has the expertise to work through this?
And so it's 2 a.m. I'm sitting here. I'm watching these alerts roll in.
I'm trying to figure out, can I deal with this? Can I deal with this myself?
Can I dismiss this? Do I need to escalate this?
And an alert comes in from our Intrusion Detection System.
And it says, hey, I saw a DNS request leaving the network,
and the host name in that DNS request matched the signature.
So the IDS raised an alert to say, I know that.
I have a signature that says that's associated with a known command and control server, a C2 server.
So what am I going to do? Can I deal with this myself?
Can I dismiss this? Do I need to escalate this?
And if I just have this data to look at this, I might start off in my DNS log.
So I mentioned there's a log for DNS, and this is a DNS-related alert.
Let me turn to my DNS log, and I'm going to see the workstation or stations, potentially,
that have tried to reach out and look up that host name.
The DNS servers that responded to that, which maybe is something internal.
Maybe it's an external DNS server, depending on how I can block that from leaving my network.
I see the query itself, which in theory my IDS already told me, so it's not really that big of a deal.
But the big one here is the answer field. It's literally called answer.
There's a field in your DNS log, and it is the response that was provided to the client.
So in this case, I know the client queried for this host name. I want to know what IP address they got back.
A lot of times, even with good DNS logging setup, if you have your DNS server set up to forward logs,
a lot of times they won't give you that last piece. They won't give you the answer, the IP address.
And I need that, because I need to pivot from my DNS log to my con log.
The question that I'm asking myself right now is, okay, I know that there was a DNS request leaving the network,
but was there a connection that followed that to the IP address that was resolved?
Maybe I had an intrusion prevention system that stopped it.
Maybe I got lucky and the attacker's infrastructure was down, and I just dodged that bullet.
But I want to know if there was a connection. I want to know more about it.
And let's say for the sake of this example, there was. There was a connection.
And so I can pivot from my DNS log to my con log, look for connections to that IP address,
say that there were connections. I want to see what ports they're on.
When did they happen? Are they still happening? How many bytes were sent either way?
And ports in particular is interesting, because I want to know a little bit more about this communication.
Let's say for the sake of this example that the communication to that server was on port 80.
Well, the more veterans of you might say, port 80 is obviously HTTP. I know that.
But hang on, put your attacker hat on for a second and think about this.
An attacker doesn't have to use the port for its intended purpose.
So just because they're on port 80 doesn't mean they're using HTTP.
But one of the cool things Zeke does is it has what's called dynamic protocol detection, DPD.
So I'll see in my con log a field called service that tells me the protocols identified.
Zeke knows, regardless of what port it's on, what's going on inside that connection.
And so it'll say, yep, I know there's HTTP inside of here. I don't care that it's on port 80.
I mean, obviously, that wouldn't be what we would expect.
But Zeke tells me certainly this has HTTP traffic.
So I'm going to pivot now from my con log to my HTTP log to get more information.
And how do I pivot between those two logs?
The connection unique identifier, that UID field.
Remember, that appears in every single log that has information about this connection.
So I'm going to look to that UID field and look to see if I have a matching entry in my HTTP log.
And in there, I'm going to see things that relate to this connection.
Things like user agent strings and cookie values, get push parameters.
Things that the browser sends as part of that request.
And also I get some response information.
And these are things that you'll hear the term indicator, or an IOC, or an indicator of compromise.
These are things that might help us figure out exactly what this is, what malware strain we're dealing with.
And that's something that, again, I might be able to go back to previous incidents and playbooks and community resources and say,
Hey, what is this thing? Does anybody recognize this string that looks a little bit weird?
Do I know what malware that's associated with?
And so, if so, I might be able to handle this myself.
I might say, all right, cool. This is an incident that I know how to resolve.
I'm going to go ahead and quarantine, you know, kick that machine off the network.
I'll contact the user. We'll start an IT ticket, get it re-imaged, and probably reset the user's password.
But, okay, I can handle it, right?
But, I like being the worst-case scenario person.
What happens if I don't know how to deal with this?
What happens if I don't have any indicators that I can pull up and say I know what malware strain this is?
Let's say, for the sake of this example, that this is a downloader.
This is a piece of malware that kind of establishes a foothold on this compromised workstation
and then beacons out to a C2 server and starts downloading additional malware.
It's going to bring back tools, things that might potentially let the attacker find a foothold on this workstation or within this network.
So, in that case, I would see all these HTTP connections and I would see mentions in my files log
so I could pivot from the HTTP log to the files log using that connection ID again
and say, hey, what files are being transferred here?
Specifically, I'm looking for... so Zeke has the ability to extract MD5, SHA-1, and SHA-256 checksum.
And so these checksums are things that, again, can be an indicator of compromise.
Another IOC that I can use and go back and say, what is this?
Maybe I don't know what the downloader is, but I can kind of know what these other tools are
and I can start to understand what the capabilities of this are.
I can also look around my network and see what other machines have seen those hashes
and maybe there's other machines that are part of this compromise that I'm just now discovering now.
But let's say... I don't know, I like being the worst case scenario person.
Let's say that the attacker gets a foothold on that machine and starts deleting evidence,
which, you know, putting my open-sock hat on for a second, it's been known to happen.
So let's say the attacker goes in and starts to clean up after themselves.
And I'm like, well, great, all the information on that endpoint now that the evidence is getting erased.
Well, remember I talked about Zeke having file extraction.
So I can pull out those files as they go across the wire, save them to disk,
and even if they get deleted, you know, zero-wise, wiped, whatever, off that workstation,
I still have those binaries.
So putting my worst case scenario hat on again, if I say, all right, well, the evidence has gone over there,
I still have these binaries that I can go back to and figure out exactly what they're capable of.
If I have to escalate this and, you know, it's 2.15 in the morning now,
and I have to call one of the senior members of my team to say, yo, this looks bad.
You know, I'm pretty sure this is an actual incident.
Here are the things that I know so far.
I know the IP address that we're getting out to.
I can tell you all the hosts that are talking to that host name or that IP address.
I have some indicators that we can potentially write some IDS signatures for so we can catch this in the future.
I have these SHA-1, MB5, and SHA-26 hashes that we can, you know, search the network,
and I can tell you what machines have this malware associated with them.
So I figured out the scope, and I mean both in time and in the hosts associated with this.
And if we have to bring in, you know, reverse engineers or, you know, malware analysis people,
they have those binaries they can start tearing through.
So even in the worst case scenario, I've got a lot of evidence here,
even without talking about anything on the endpoint at all.
So I know I belabor this quite a bit,
but I think it's powerful to talk through kind of the questions that you'll be asking yourself
as you're going through something like an open-socket exercise or a real-world exercise.
They're shockingly similar.
And also to understand where you go in the ZEKE data to understand those questions a little bit better.
So there's many ways, as I mentioned, that this ZEKE data can be represented.
So here I have a screenshot of Splunk, which is, you know, you can get a free version and pipe the data into Splunk.
And so, sure, that's a thing, you know, if you're a Splunk person.
We had a talk earlier on Kibana.
Instead of asking if you're using the Elastic, the Elk stack,
you can feed this data into Kibana and look at it that way as well.
But our tool of choice in open-socket is going to be Greylock.
And so you should get comfortable with what this looks like in Greylock.
So to start off with, when you get access to the open-socket environment and you go to Greylock,
you might end up looking at a screen like this.
When you click on the screens, you're just going to get the stream of data.
This is everything that's going across the network right now. It's a ton of data, right?
And so as you're looking through this, I want to talk to you a little bit about the Greylock interface,
but also we'll use it to kind of talk about what the ZEKE data will look like.
So to start off with, you'll notice that I've typed a query into my Greylock window here that I am looking for ZEKE data.
Specifically, I am asking Greylock to search for a field called event type,
and I want you to tell me when that event type equals ZEKE.
And so this is going to limit down the events that are returned back to me as part of this UI.
And so this is a gotcha that you'll find again and again, especially in open-socket,
where you'll be looking for an artifact and you're like, I can't find it, it's not here, I don't know where it is.
It's because you probably have your search set to the last five minutes,
and if you're looking for something that happened several hours ago, well, yeah, you're not going to see it.
So I'm also going to go ahead and turn down, or turn up, I guess you could say, my search window to a larger window.
Maybe I have a particular time span and I can input that, but right now I'm just kind of taking a casual stroll through the data.
So with those things, I'm going to scroll down a little bit, and on the right-hand side here, you see the Greylock events.
And so these are Zeek events, specifically, and you'll notice there's a lot of them, but each one of these is a Zeek log,
a line in a Zeek log that's giving me some information about communication that happened.
And if I click on any given one of them, you'll notice the event type is Zeek, that's why this was returned.
And there's a lot of information here inside this particular log entry.
The first thing that you should look at, the first thing I want you to get familiar with, is this file field.
And the file field tells me which type of log is this.
In this particular case, I'm looking at a MySQL log or a MySQL log.
So this is going to have information about a database transaction that occurred here.
Now, if you look down a little bit further, you will see the message, which is the line.
These are the individual fields of the MySQL log.
Now, there's one thing I'm going to come completely clean here, and some of the logs that you'll see, they're really parsed that cleanly.
So for something like this, I have to kind of turn back to some of those cheat feeds for that documentation to figure out, like, what does each field mean?
Like, I can see the first field is a timestamp, and the second field that starts with a C, that's my connection unique ID, so that's something I can pivot off of.
I see some IP addresses, some ports, I see a MySQL query.
Sometimes it's a little self-explanatory, but refer to that documentation as needed.
Let me give you another example here.
So I'm scrolling down, looking at another entry.
Again, event type is Zeke, that'll be consistent.
But instead now, I'm looking at the con log, so this is that connection log.
This is giving me information about a connection that occurred.
And I see the message down here that those fields, which you'll also notice, all the fields have been broken out for me.
So I can see the connection state, the destination IP.
There's a Boolean that tells me, is that inside my network?
And that's a Zeke variable that gets set.
I get to see, you know, the destination port.
The history field is actually a really interesting one.
I don't have nearly enough time to dive into it, but it's really well documented.
And it tells you kind of the order of things that happened inside the communication.
So there's a lot of things here.
And also, you'll notice, I could scroll down, but I can also see it here in the message field, that connection unique ID.
So, sure, there's a connection here.
All right, it's on port 80.
Is it HTTP?
Well, I see HTTP in my message there.
And if I were to scroll down, I would see that as part of my service field.
But I can look and search, write a great log query to search for that connection unique ID, and find all the information associated with this particular connection.
So as we scroll down a little bit further...
Oh, look, here's an HTTP log entry.
And so this file here tells me I'm looking at the HTTP log.
I get a little information from the client side.
So it looks like this was a GET request for the slash link on the root page.
So I can see a little bit of information from the client.
I can see a little bit of information from the server.
I respond back with a 200 OK, which is perfectly normal.
Right.
At least that's what I would generally expect.
And so all these fields, again, are broken out for me as I work my way through.
One more log entry I want to talk about is the files log.
So I mentioned that whenever we see a file transfer, the example I used was HTTP.
But it actually works over SMB, SMTP, HTTP, FTP.
I'm sure I'm forgetting many of them.
But fundamentally, if we can see a file transfer that's happening, we can pull that off the wire.
And so you'll see an entry in your files log that gives you things like the LIME type.
So, oh, this looks like it was an MP4 video.
I get those hashes, those checksum values, which in the case of a video...
Maybe that's interesting or not.
Or a document, that might be a lot more interesting.
That might be something that would be a very interesting indicator to key off of.
In some cases, you'll see the file name.
In this particular case, this was part of an HTTP connection that just wasn't provided in a header.
We just couldn't extract it for one reason or another.
But if we do get the opportunity to pull a file name off the wire, we'll happily do that.
There's one thing that I didn't have an arrow to on the slide.
And that, as you'll notice just under the file name, is the file unique ID.
And so similar to the connection unique ID that starts with a C, the file unique ID starts with an F.
And that tells me that this is associated with a file transfer.
So there's a lot of data.
I'm just giving you the highlights, and I promise you're going to see some of those in some OpenSock scenarios later.
Not that, you know, I don't want to spoil too much.
I'll put these URLs in the Discord chat as well.
I'll also post a PDF of these slides, so you'll have these.
But these are the two resources I would suggest to get comfortable with Zik data.
So the thing on the left is the PDF. I like it because it's searchable.
The thing on the right is the Zik documentation from Read the Docs that does a much better job of going into more depth
and has more logs that didn't really make the cut on the cheat sheet.
So I only have a few minutes left, and I want to talk very briefly about the Zik community.
And by all rights, this would be Amber here talking about, as a community director, she would talk authoritatively about this.
And there's so much that's going on now and on the roadmap.
Fundamentally, the things that you should know about is head to Zik.org slash connect.
So Zik.org is the Zik website. They've got a YouTube channel.
They've got a Twitter account that's constantly posting and retweeting new packages
and things that are relevant to current vulnerabilities that are blowing up Twitter.
Zik started a Slack organization, a Slack channel, which Discord... I'm working on it.
Slack is the home of a lot of these really great conversations that you can have alongside the Zik developers,
the package developers, and they're a really approachable community.
That said, because it has such a long history to it, there are also some very good mailing lists that you should join as well.
On the bottom left, you see there are a lot of in-person events, obviously not happening at the moment.
But keep an eye out if you hear Zik Hour, Zik Days. These are kind of local organizations,
so you can kind of come and hang out for a happy hour and meet people.
In fact, you can kind of help Amber organize your own if this is something that you want to bring to your area.
I'll give you her contact information. She'll be eager to talk to you.
Zik Week is actually an annual event that we do, so it's all these conversations about Zik package development.
Things from like, how are Blue Teamers using this to defend themselves,
all the way down to like the lowest internals of the Zik ecosystem.
There are also now a lot of virtual events that are happening.
So if you check out the Zik.org site or the Zik Slack, you'll hear about a lot of online events that are happening.
There's Zik from Home, there's Ask the Zik-sperts, which is where they bring in a lot of experts,
and you can just be like, hey, I'm trying to install Zik at home, and I'm hitting this error,
and they'll happily walk you through it. Super, super approachable community.
And to that end, I would encourage you to contribute to that community.
So a lot of folks, especially approaching open source, think, well, hey, I'm just getting started,
or hey, you know, yeah, I'm working on this Blue Team thing, and I'm figuring this out,
but I don't know anything about development or, well, anything about what seems like it would be needed here.
And I want to dispel that, because there's so many skills that are required to make this work.
So yes, you might be thinking in code. You might be saying, well, I'm not a good coder.
Well, okay, what about looking into the user community and contributing to, as you're installing this,
and you're saying, hey, this documentation, you know, is a little bit unclear.
Or, hey, I tried to do this, and this documentation didn't work for me.
Let me fire off something on the mailing list and say, hey, I have some suggestions.
How do I, you know, make some proposals to the documentation?
Maybe you want to try your hand at scripting. Scripting is actually pretty approachable,
and there's so much that you can do in the Zika language.
Things that are just very simple that are going to help you in your day-to-day,
versus like, hey, there's a protocol I just want to tear into, whatever that might be.
Maybe you're just saying, hey, you know, I don't know anything about Zika yet.
Where could I start? Download it. Get some of the latest releases and give us an okay and say, yep, we tested it out.
It worked. Help us test releases and get that feedback.
So there's so much that you can do, and it's so tempting to think of this as like,
I'm at the bottom of this ladder, and I don't have the skills that I need to climb it.
And Amber has this awesome metaphor about, think of this as a lattice.
Think about kind of moving diagonally. Think about kind of charting your own path
and building your own skill set as you're contributing back to the community.
This goes for so many communities, but I think for Zika, it's especially true.
So there are a couple links that I threw down earlier, the link to the Zika documentation.
So if you're interested in deploying Zika locally, probably something I would recommend putting on
until after OpenStock, because you're going to have a busy weekend.
But you've got the link there. Again, I'll post these in the Discord.
Security Onion, a lot of you know, as kind of the Cali for blue team,
it's a Linux distribution that has all of these tools built into them, including Zika.
And so if you're interested in just having kind of a live environment,
I wouldn't recommend it for like a full production environment,
but for just getting your feet wet and understanding how this works together with these other tools,
Security Onion is a fantastic starting point.
I mentioned that PDF, so I've got the link to the PDF there.
And oh, by the way, there's this event that's happening called OpenStock.
If you haven't joined the OpenStock Discord yet, there's a lot that's happening there.
It starts tomorrow, but you can swing on by, you can get registered and set up.
Check out the DC28 OpenStock CTF in the Blue Team Village Discord for more information about that.
So with that said, I think I am pretty darn close to time here.
I want to leave you with my contact info, Aaron Soto at Corelite.com.
Amber is our Zika Community Director, an incredible resource,
and just constantly has these amazing plans for the Zika community and helping it grow.
So if you are interested at all, there's also a Zikurity Twitter account that I mentioned.
There's a Zik channel in that OpenStock Discord.
So even if you're not going to play OpenStock, come join the Zik channel and kind of have the conversation there.
Keep an eye out for a lot of these online events. As I mentioned, Zik From Home, Ask the Zik Experts.
There's a lot more on the way that I'm sure Amber could write a lot.
And we're also doing, not quite as cool as OpenStock, I'll admit,
but some community CTFs to help you learn the Zik environment.
So with that said, I know I am pretty darn close to time.
Did we have any questions from the chat?
I'm going to scroll and kind of take a quick look here, but if you have any...
I'm actually happy to have a conversation with folks afterwards.
As I know, we are pretty darn close.
I'm hearing people ask about, you know, how hard is it to set up?
I'd encourage you if you...