Building the Panopticon: Centralized Logging and Alerting With Free Tools

Yes. All right. He's recording now. Okay. So do you want to? Yeah, you can start. All right. Good morning, everybody. What are we doing? I was really excited to see you at the 9 a.m. time slot. I feel like I'm teaching freshman computer science again. Would anybody like to learn about linked lists through one bloodshot eye? Anybody? Fantastic. See you after class. So the name of this talk is building the panopticon. Centralized logging, alerting with free tools. So if that's the target you wanted to see, that's the one you are in. Who am I? My name's Matt Gracie, as it said on the title slide. I've been working 19 for about 20 years. I've been working specifically in InfoSec for about 12. I am

a blue team defender, defensive operations, real time monitor, and can't happen. That's what I've done for my whole career. I actually grew up in Henrietta, not that far from this campus. I guess my first security job was parking lot security at the bar across the street, and it was still Red Creek before it became the Breggers. My first information security job was in higher ed in a college in Buffalo. And I've always told people that working in higher ed is the best possible training for an info sector. You're on a network where you have no control over the endpoints. Half the people on it are actively hostile and you have no money to fix anything. So that was where I got my start.

That was where I got very small paychecks and a staggering knowledge of this. And that is where I started working with a lot of the tools that I'm going to be talking about today. The point of this is to explain the tool chain that I built and I've deployed in production at Axle for doing centralized logging and alerting at an enterprise network for zero additional dollars. Now, what is the Panopticon? This is a concept that was pioneered by Jeremy Bentham, an English social scientist in the 17th century. You'll have to forgive me, my first undergraduate degree is in English, so if I don't make at least one tiresome metaphor per presentation, then you'll poke it. His idea was that you

could architect a building People generally think of it as prisons but also factories or any place where you have multiple people. And through architecture you could set it up so that a single watchman could observe everything that's going on in the building. And the people who were being observed would not know whose eyes the watchman were on in any particular time. Now during his lifetime he never got to build it. But the idea was actually used in a few places. This is what was called the F House at Stateville Correctional in Jolene, Illinois. You may recognize it from the movie Natural Born Killers. It's part of the set in the riot scene there. Or this

is another one, Presidio Morello in Cuba, where the Castro brothers were held. And as you can see, the architecture is basically a guard tower in the middle for observation. All of the cells are open so that one guard can watch everything that's happening in the prison at the same time. Now as blue teamers and defenders, that's what we want on our networks, right? We want one place where we can sit down and look at the logs, look at the alerts, and see everything that's happening on our network without having to go in and check each machine individually, check each log trailer individually, et cetera. So we want something that looks kind of like this. Now this is obviously sort of a

stylized ideal topology. It's not really going to be feeding everything into just One box, one hop away very neatly. But there's another diagram later in the presentation where I show how it actually works and how the actual data flows are set up. Not that dissimilar from this, believe it or not.

So, we have to make a few assumptions. First of all, you're working in a not exclusively, but at least primarily Windows-based environment, running a modern version of Active Directory. By modern I mean 2008 R2. So really by modern I mean supported in some way. The clients can be any supported version of Windows and it can also be the 2003 XP clients that we all have on our networks and are unwilling to talk about in public. So we will pull logs from Windows as well. You have already enabled advanced audit policy on your domain. What this does is it turns on some additional auditing rules, lets you audit things like directory object changes that are not audited by default. You want to set those up, turn

them on. The documentation went to the Microsoft database. It's really simple to do with a policy, but it adds a lot of robustness to your logs and gives you a lot more information. The third bullet point, layer eight problems are always the toughest ones. You have enough buy-in from your system administrators to make some wide-ranging infrastructure changes. Now this is nothing major, this is nothing destructive, but depending on how your organization is structured, This may require more or less finessing. I've been in situations where I've come in and I've been the first dedicated security person in a company, and I got a lot of pushback from the infrastructure. People have always done it this way, we don't want to do it that way, et

cetera, et cetera. So this is not a hardware to software, but it's a personnel problem. One useful technique is pointing out that the stuff that you're deploying is actually really helpful in terms of diagnostics. I've always said that 99% of a successful information security program is a successful system administration program. This can help you track out accounts, find stuff, find lost in passwords, find missing patches, et cetera. So, you can use that as a . And also, your organization has to be amenable to use free or open source software. Again, I've been in places where the assumptions that anything you deploy in the network has to come from a group vendor, We are pretty better in the list, has got a support contract, et cetera,

et cetera. As most of you know, if you've been working in security for a lot of time, by the time a company like Dell figures out that there's a niche for a product, that there's a threat that they're not addressing yet, it's already not been a threat for four years and everybody has moved on. So you need to be a little more nimble on that. You need to be in an organization that's willing to make changes and move quickly and use a lot of stuff. Because honestly, in security, that's what most of the good stuff is. So, these are the tools we're going to use. We're not actually going to use Microsoft Windows for work groups, but for those of us of a certain age, this will

always be Microsoft's logo. So that's the one that I always use. We're using a facility built in Windows called Windows Event Forwarding. Has anyone used that before? All right, it's good people, good. We're using a space-based IDS called OSIC. Anyone use that one? Okay. And for the actual visualization and alerting portion, we're using security onion. Then we use that. All right. Again, this is a very potent combination of products, and it's all free. The Windows event forwarding stuff is built right into the Windows. If you have a Windows environment, you are already licensed for it. You already have it. You just need to turn it on. OSAC is a free download. It's owned by Trendy Micro now. It

is an open source project. You can download it. You can modify it. You can do whatever you want to it. And Security Onion, we'll talk about more in depth, but is a security-based Linux distribution built on top of Ubuntu. They were also kind enough to massively overhaul part of their product on Monday. So some of these slides might look a little funny because I made them all on Tuesday. All right, so this functionality is built into Windows Server starting with Windows 2008. It's called Windows Event Forwarding. The idea is because Microsoft apparently didn't want to pay any of their programmers to make syslog work properly, like it was on every other license on the planet,

you can centralize Windows events and have them forwarded across the network to one collector server. You designate one server, and it doesn't have to be a particularly powerful server, it just has to have a fair amount of disk space, as a log collector. So this is the server that sits someplace that's accessible to everything else on your network. And you can do multiple collectors if you want. You want to have a set of 1DVDMZ versus your protected network. You designate that as a collector. The collector server is configured with what are called subscriptions. Now, if you've ever been an event viewer on Windows Server, you probably see a little thing at the bottom that says subscriptions. You probably never clicked on it. What subscriptions are, are lists

of criteria for what logs to forward. So you can set up a subscription and say every logon event forward to this collector server. Every failed logout attempt forward to this collector server. You don't have to do them one by one like that. You can do ranges, you can import whole logs if you want to. But what it'll do is it'll send it either across HTTP or HTTPS using the Windows Webinar Management tools, the CRM, to move this data to your centralized collector server and storing a log there. You deploy a GPO. that tells domain computers where this subscription server is, where this collector server is. And then events that you designated in the subscriptions are now forwarded to your collector. It's a pretty straightforward

process. You designate the collector, you write the subscriptions, you push out the GPO telling your client computers where the subscription manager is, where it should treat the subscriptions from, and then the events just start evolving. It's pretty straightforward. This is what the GPO actually looks like. There's really only two components to it. I'll try not to destroy the microphone here. This one is the subscription manager portion. Because I'm super clever, I named the log collector Sawmill.

Anyway. So what it's doing is it's telling the computers, okay, this is your subscription manager. Check in here, refresh 60. So check in here every 60 minutes to see if any subscriptions have changed. And whatever you find there, forward it along to Sawmill. And then this is a second item allowing the network service, which is the context that this process runs under, to read the security logs on the effective machines. So you're saying, let network service read the logs and then forward along the logs that match the subscriptions to Sawmill, to our centralized server.

This is what the actual subscription properties look like. So in this case, it's a very simple one. The subscription name is security log clear. You can somebody by naming it through the command line or through the event viewer application. Clear on the security log in the effective machine. That fires off an event ID 1102.

So what this is saying is if you see anything with an event ID 1102 forwarded into our collector server. destination log is where you want it to go on the collector server which dump everything into forwarded events. You can filter it out later, we'll talk about that in a minute. Now this is interesting where it says select computer groups. You don't necessarily have to have enterprise wide subscriptions. If there are particular events that you're concerned about, but only in particular pools, you can assign these subscriptions to computers, you can assign them to groups, you can assign them to OUs, you can assign overlapping ones, so maybe you want to collect any group membership changes from your domain controllers,

but you want to collect only administrator group changes from your member servers and your workstations. You can have sort of granularity in how you architect this and what logic . Again, in this case it's very simple, we're just saying 1102 anywhere on the network, if it shows up, forward it along. Here's what it looks like when it works. This is the event viewer application built into Windows. As you can see, we're looking at the forward events log. We have those logs there. A computer named member, which is a member server, because the unit is very creative, has had its security log cleared. They cleared an event, 1102, as listed right there. Here's the name of the account that cleared it, adminmg. And all of the success.

the time and date and person that cleared it. If you see this in your environment and it's not something that you would expect from your administrative team or if it's being done by a service account or some other strange account, obviously this would merit additional investigation. The best part is because we're centralized on logs, the local logs doesn't do them any good. They can clear it and all they're doing is shooting a flare gun in the sky and saying, I'm here. Now go look at all the other ones that were forwarded from this box because obviously I'm trying to hide something.

So what events do you monitor? You see at the bottom here, I'm quoting Jessica Payne who gave a paper called Monitor on What Matters. I think it's three or four years old now. Absolutely fantastic paper. Jessica works for Microsoft. She does a lot of talks on this kind of stuff. I would definitely Google for that and look it over. It's also got step-by-step instructions on setting up this . Hersey questions for what to monitor. Security event logs being cleared. Again, typical adversary tactic, and you've done something, you want to cover your tracks, clear all the logs, that will alert you that something's strange . High-value groups like domain admins being shaped. Because I'm sure we all work in completely compliant environments,

nobody has overlapping responsibilities, everybody has dedicated domain admin accounts. But on the off chance that there may be a couple stragglers around, this gives you a really good chance to see what activities are going on in terms of membership in these privileged groups. You can watch domain admins, schema admins, enterprise admins, any of these built in high privilege Watch them on your domain controllers and see what's happening with them. People are being added, people are being taken away, et cetera. Local administrator groups being changed. If user accounts suddenly begin to add in on one of your member servers, but not in DC, just on the local member server. You probably never even look there. But if you've got this set up, it's not going to be long

to go into one place. It's a good time. Local users that are unexpected being created or deleted, who just made a user named PSEXAC in our finance system?

And new services being installed, especially on domain controllers. So if something like PSEXAC fires off or some other new service opens up and starts listing on a port or something else is done in terms of persistence on that server, you have a good chance of catching it, seeing what's going on, and see what's up. All this logging will come with date, time, name of the user that didn't, et cetera. Again, it's all getting dumped into one place, so it's easy to search and try to figure out what's going on. What else should you do? Well, you can read this paper from our friends at the NSA. Might as well get something for our tax dollars, right? There's a lot of good stuff in here. Specific two users

of that long monitoring. Changes to schedule tasks is a huge one. A lot of the APT groups use this as a persistence mechanism. So watch for any changes to schedule tasks. Password resets, you know, everybody has that one user, can never remember their password and it has to be reset by the admin, that's fine. You look at the logs in that same admin and it kind of resets seven other passwords in the last two minutes. No one asking what's going on. You know, sometimes it's just everybody went on vacation and forgot their password. Sometimes it's somebody building up their system nine minutes or so later. Software installations. Anything you do with Windows installer, writes events, those events can be collected. Account creation, account enabling. If you

have an account for an employee who left two years ago and something gets turned on again or something gets changed, what's going on? That could be a sign of some sort of massiness. Honey tokens. This is an interesting use case. You can do something like create an account and make it super duper global galaxy admin or something subtle. And then give it all the rights in the world and set the login schedule to never allow it to login. So it's a valid account, but it can never login, it can never do anything. Well if somebody tries to use it, it's still going to throw a login failure. It's still going to get slurped up into your logs. So if you put those

credentials, say in a spreadsheet and passwords on your DC, that nobody should know and then suddenly they get used, there's something going on. Somebody pulled that spreadsheet on your PC. You should do something. Legacy accounts. This is another example of how we can help out our infrastructure people with this sort of infrastructure. We had a service account in one of our places that was in the enterprise admin's group. So it had access to literally everything and had like a five character password on it that everybody knew. because the developers were using it to do scheduled tasks, the SQL guys were using it to do databases, it was just an open secret that everybody had access to. And as you can imagine, it gave me hives

as a security guy. So we were able to use a system similar to this to track down every last place on a network that that account would be used, shut them all down, and move them all to proper service accounts. So I've given you tremendous help in terms of enforcing account hygiene in your environment. Another thing I like to track, RDP logins. Once a week, dump out a list of all of the accounts that did an RDP authentication. Are your admins in there? Great, they should be. Are some of your super users in there who might have access to specific machines? Yeah, that's great. Is the service account for your backup software RDPing? Why? We've all got these privileged service accounts floating

around that aren't supposed to be doing any of this stuff, but not always locked down entirely. So, a good check to make sure that stuff's not being used.

Now, if the normal logging isn't enough for you and you want extra information, there's a product from Microsoft Sysinternals called Sysmon. People use Sysmon? Okay. It lets you log even more stuff. So, the normal Windows logs will log things like logins, logouts, failed logins, RDP access, et cetera, et cetera. SysMod gives you really tight, granular logging of most system events. So stuff like a process was launched, a process was terminated, a file was created. This is the kind of stuff you would get from a very expensive EDR solution. So if you're in a shop that uses carbon black, this is the kind of stuff you get on a carbon black, except it's free. Sysmod is a free download from Microsoft. They're all . There's a lot of really good

forensic data that it can gather, and it can also be integrated into this event forwarding stuff. So if you have a very high-value workstation, say you've got somebody in finance who does all your wire transfers, and you want to keep a super-tight eye on that, you can put Sysmod on their box, and literally everything that they do will go into your logging infrastructure for potential . It's a very powerful tool. Now, the downside of this of course is all of this is moving over the network, right? So if you've got 50 machines, it's a lot easier to deploy this than if you've got 2,000 and you've got all this bandwidth being used up on logging data. On the positive side, a network that's completely saturated with logging data

is going to be unusable for an attacker. But that's really not what we thought. Even if you decide you want to deploy SysMod, you don't have to necessarily collect those logs from the machines. You can have them stored locally and use them for forensics after the fact. So if you see something suspicious in the normal logs, then you can visit the user's computer and take a look and see if there's anything in these super, super extra SysMod logs. So this is what it looks like as part of the event forwarding structure. Right here we've got a process create event, here we have a process doy, the command line, current directory, user running ads, et cetera, et cetera. Any information you could possibly want is in there. Hash values, parent

process, everything you need to know about this process, where it came from, why it was launched, where it's going, when it dies, et cetera. Sysmine is a very complicated tool. It can be deployed with an XML based configuration file. So you can put it into production sort of auto configure it. Does anyone follow Swift on Security? Okay, awesome. Swift on Security did a system on configuration that is fantastic. It is very well commented. So if you're new to the tool, I would suggest going to the GitHub for it, pulling it down, taking a look. Even if you don't deploy it, it's a very good learning tool, a very good documentation tool. product documentation from Microsoft and the little sparks and spots that fills in a lot of the holes.

Alright, so now you've got all your Windows logs in one place. You've got one box, you've dumped everything into it, what do you do with it? Well there's a few Windows native applications that we can use at this point. The built-in event viewer will work on forwarded events the same way it works on local events. So if you go into Event Viewer, you look at forwarded events, you'll get that two pane interface, you'll get the impossibly broken find function, you'll get the inability to export to anything useful, it's really a wonderland of functionality. But the two big problems with it, one, depending on the size of your network, it may roll over event logs fairly often. The last place I deployed

this was about 120 servers or so. And they were pushing out, with a relatively sparse subscription set, they were pushing out two to three gigs of logs per day. So if you're rolling over to two gigs, that means you go into the event viewer, you're only looking at the current event file. If you want to look at anything that's more than 16 or 24 hours old, you have to go figure out what file it's in, attach it to a vet viewer, it's kind of a hassle. So this works in, for limited, I just need to find one thing and I know right where it is. But as a day to day tool, it's not what it's built for

anymore. Microsoft has a tool, and it gave us a free download called Log Purser, which is a command line tool, and Log Purser Studio, which is the more visual gui-fine tool for querying these log files. Now it'll also query IIS files and so on, but specifically it allows you to write SQL style queries against event log files. So I can say, okay, give me a CSV with everything matching this event ID, and then there's a field in there called strings, which is the actual content to the log, and then separate out seventh value of strings, which I know is the login type. And if that's equal to 10, then put it in the CSV. So that'll go back through all my event logs and

give me just a CSV file with the information about RDP logins. Or any other specific reporting requirements that I have. I can go in and grab that stuff. So that's a very cool tool. Works really well.

One other nice thing about it is The LogParsher Studio software itself allows you to test these queries, make sure they work, and then export them as PowerShell scripts. So if you wanted to, you could say, okay, this is something that I need to pull out of my log files every night or every six hours or once a week or whatever, kick it out into PowerShell, set it up as a scheduled task, and then you've got a directory that's just got these pre-analyzed, pre-parsed, ready-to-review CSV files sitting in it. They're being auto-generated. It makes life a lot easier. Power BI Desktop is another free tool from Microsoft. And this allows you to take those CSV files

and do sort of more advanced dashboarding and analytics on them. You can take the last six months of login CSVs, drop them out there and get a pie chart that says who logged in the most, from where, from when, slice and dice the data however you want. Jessica Payne, who I referenced a couple slides ago, she has a really good article on Power BI Desktop. with Windows event forwarding as a front response tool, or as an instant response tool rather. Last time I checked it was the pinned tweet on her timeline. Definitely check that out as well. She's got a sample Power BI desktop config in there that's very powerful, a lot of cool stuff.

So, what's the next step? Well the next step is we want to take these logs and somehow process them so that the stuff that's high priority and stuff that's really important gets raised to the top. Because if you're on a large enterprise network, you get thousands of these logs every day. You're not going to investigate every single line of every single log. You need somebody to triage it. So the first thing we need is OSAC. OSAC is an agent-based platform. You install an agent on your endpoint. tell it what files to monitor. So it can monitor for things like registry changes, it can monitor for things like log file updates, it can monitor for anything you

change on your disk. Those changes and the events for proper changes are then forwarded to a central server. The central server has an analysis rule set on it. The rule set then raises alerts based on criteria that they set out. And alerts can be handled in a variety of ways. You can have alerts that send an email, you can have alerts, you know, do an SMS if you have an SMS gateway. What we're doing with this architecture, we're going to have the alerts show up in sort of the reporting dashboard.

So for this architecture, we installed the agent on the collector server where our Windows event forwarding stuff is. We had a report to the OSAC server, which is a security on here, the second machine that we're going to set up. and then we write rules on the security server to evaluate these incoming events and raise cards.

I have a note on this slide that says, this slide totally isn't because I forgot to do this stuff this week when I was opening my slide back. The collector server must be whitelisted in the firewall rules on the security server. And the OSEC agent on the web collection server must be configured to launch the forwarded events log. It's not configured to launch the events. When we get to the end, we've got a GitHub set up with configuration files and all the other stuff, all the syntax explaining how to do everything they're talking about. So you can go to the Gratman. All right. And our last piece is the security onion. The security onion is a bunch-based platform for Gratman tech.

It includes a lot of really good data gathering and analysis tools, including OSEC, including Squeal and Squirt, which are tied by the net. It uses a server-slash-sensor architecture. For this use case, we're only using server components. So we're using the server or the master server part of security. We're not necessarily using the sensor part. That said, if you have budget to buy a couple of commodity servers and throw a bunch of disks in them, The sensor components are fantastically useful. They are very, very cool, very helpful. They do full packet capture. They do IDS analysis of traffic. They do bro logging. You can take all your bro logs from security and fire it right into for frequency analysis and beacon hunting and all kinds

of cool stuff. So the server stuff that we're going to talk about today, the sensor stuff is also super, super useful. Keep that in mind. I

have deployed $20,000 security on deployments that did full packet capture for an enterprise and absolutely opened the doors off quarter million dollar enterprise . So again, the OSC agent on the left collector, what fully the collector was, the security And rules on security, partial logs, and raise alerts as necessary.

So this is what the rules look like. It's a fairly simple XML syntax. You can see like, I guess what the third one down there, security map log here. So that's the alert that we've been talking about while presentation. If you have to stick with it, if an alert comes in, If the parsing rule shows that it has event ID 1102 in it, and OSEC can parse for the most formant to pull out the event ID, then that is a security event block cleared event. You need to raise the load. We've got some other material. Scheduled task, updated, scheduled task, completed, password resets, et cetera, et cetera. So, OSEC monitors all of the incoming traffic from your WEF collector. And whenever it sees something

along these rules, it triggers an alert. So like here, our web collector, the auto log is cleared. And then here in squeal, which is the reporting application, we see it pops up an alert immediately. It says, hey, the security event log is cleared on this box here by this user. So here's what's going on. Squeal is a, Linux native FAT application, I'm told that there is a JavaScript base, the Angular JS whatever web version coming. I'm not a web guy so I don't know exactly how they built it. There was an announcement for it but it was on April Fool's Day so I don't know how serious it would take it. This can run on anything with Xwindows.

I've used it on a Windows workstation running X server to export it from my security environment. And then when anything weird that you've written on Word4 pops up in your logs, you get an announcement. Hey, the security blog is clear. Hey, the scheduled task was updated. With all the metadata that you need to go in and dig and figure out what happened. There's also a web-based product called Squirt. that comes with Security Onion. It shows the same alerts. The workflow is a little bit different than with Squeal. I'm just used to Squeal, I guess. But you pull out the same stuff and we'll get historical trending, what sort of alerts you've been getting over time, et cetera, et cetera. Now this is

the stuff that just updated this week.

Security Onion used to use a product called ELSA, which is an enterprise log search archive I think. They switched over to using the Elastic Stack. This change was announced at the Security Onion conference last year. It will be coming soon. Soon ended up being a few months longer than people expected, but it finally went to open master and production this week. So as of Monday, if you downloaded Security Onion, you would get the version to come from Elastic Stack. So that means all of these logs are coming in, they're going into a blog snatched database, they're sitting on the back end there, it's indexed via Elasticsearch, and Kibana is reporting for them to go in and dig through all your blog data and look for anomalies,

it looks weird. So, if you go in and you say, okay, well show me all the 1102s, you've got a search box at the top, we have approval style, you say, okay, 1102, show me anything with that text in it that has come through and you'll show it. it pops up on a particular server where you weren't expecting it, you can say, okay, this is coming up on member.canopticon.local, I'll just search for that server name, and it'll bring up all the logs from that server. So you can see, if you've got sysmod, okay, what processes we're running, who's logged in, what's happening, what network connections are being opened, what potentially nefarious activity am I seeing on that server that is resulting in a clearing event.

all kinds of other functionality built into it so you can focus in and really work on hunting down the threat and figuring out what exactly happened. Another cool use case for it, if you've got Sysmon, is you can do hash hunting. Say you get a piece of threat intelligence that there's malware for your industry, it's got MD5 and SHA-1 hashes attached to it. You can go into this console, plunk the hash value into your search field, And if you've got Sysmon deployed, it will tell you anywhere in your environment that that hash, that an executable of that hash was executed. Enterprise-wide. So again, this is the kind of stuff that people buy carbon black or the EDR products for. You can really build

it with free tools if you want. In this case, it was me running MS Paint, which I apologize for.

Again, this principle works for any DXD. Say you've got some piece of ransomware that your mail gateway left through, you can search and see everywhere where the user is, is running and shut them down before we start spraying it on the other users. Or if you've got some sort of correction, you can do the same thing. Get a report on everywhere that it's executed.

Also, in the vein of helping out our administrators, One really useful thing you can do with this functionality is sort of focusing on obsolete software. Say you've got a piece of enterprise software, and again, it's purely theoretical, I'm sure it applies to no media in this room, all are very tight ships. But say you've got a piece of enterprise software that requires Java 6. On a Java 6, it's no longer a system of Java. You've got a, I'm talking a little version, like 6.11, something like that. I don't want to say obsolete because that sounds mean, but it's a vintage collectible version of Java. If there's one enterprise app that requires it, you've deployed it

everywhere. It's part of your standard workstation build. And you decide that having these giant security holes in your environment is probably a bad thing. But you don't know who's actually using it. You know where it's installed because it's in SCCM or whatever, whatever your configuration management tool is. But you don't know which users are actually still using this legacy app. You can go into a system like this and say, OK, show me everybody who's executed the java.exe with this hash in the last week. Kick out a report and give it to your infrastructure guys and say, OK, these are the people who still need it. Put Emmet on their machines or some other copy-saving control

and just pull it off everybody else. And you can drastically lower your attack surface without impacting your users. It's really sort of the point where

Now clearly not every device is going to speak Windows about natively. As in so many things Microsoft sort of went out on their own with their logging syntax and protocol. So you're going to have other stuff that you want to integrate into the centralized logging and alerting that isn't coming through your web server. Fortunately, security enemies can also accept logging information via syslogging. So if you have network infrastructure for example that you want to integrate into security on the environment, we just point them right at there. If you have, excuse me, if you have Linux boxes or other operating systems, OS X boxes, stuff like that, you can do it via syslog or you can install the OSAC client on them, push the

event data to your collector via OSAC and then go through that same rule evaluation that you did with the Linux events. So you get a lot of the same functionality.

if you have some legacy system that only speaks to Syslog and you really want to do OSC monitoring. Security I mean uses Syslog NG for Syslog receipt. Syslog NG is one of those like Swiss Army knife products that can do a little bit of everything. The website says, uses a Perl-like configuration syntax as if it's a good thing. But you can configure it to take any syslog stuff that matches a particular pattern. Like I want any syslog from this device to come in and be immediately written out to this log file here. So say you've got a semantic console, like a semantic AV control console that speaks syslog. You tell it, okay, spit that to security over syslog. Security onion, syslog ng, take anything from that IP

address, write it out to semantic.log, and then tell your OSAC server, you watch semantic.log and throw an alert whenever something pops up that says real-time scam or threat detected or coupon printer again. So that way you can tie syslog stuff straight into your OSAC and therefore straight into your alerting class. The partial rules for this is all written in a file called local-emotional-rules.xml. Again, I've got an example up on GitHub for the presentation. So it's not quite as neat as that slide at the beginning, but this is what your actual deployment ends up looking like. You've got your servers and your desktops and whatever other stuff you want to monitor, speaking events, you know, the Windows event

protocol to your ref collector. The operator is then speaking OSET over to security. Your other devices, in this case we've got a wireless AP, are speaking syslog straight into security on them. And then you, the faceless analyst, are logging into your security on the environment and getting these alerts and searching for logs. Everything is in one place, everything is alertable, everything is neatly packaged, and you can do it all for no money, which is pretty awesome. So my particular workflow with this was use this for daily threat hunting and daily sort of network monitoring analysis. And then because the events on the web collector are still there, we have to go forward it. Also run weekly batches from that Logparser Studio product just to make sure I didn't miss

anything. I don't know if that works for everybody, but that proved to be a really robust model for the way I undertow this.

Okay, that's about it for conclusions. We've got a few minutes left. If anybody has questions, I'll just put up the information slide. So I'm on Twitter, I think what's up here. There's my email address if you have any questions. There's the GitHub. I'll put the slides up on GitHub too. I'll put the PDF version so you don't have to see my notes and my terrible jokes. And we'll all go up there and there's sample XML file, sample subscriptions, sample OSAP config, everything that you would need to deploy this in the test environment player. Any

questions? So basically you referenced use cases at that point several times during your presentation. What are your favorite use cases that you've been able to deploy using this so that you have value, you're not just static you know, information in there, but you're actually having it do some enrichment enhancement and give you better value for the statics of it's in there. Okay. I'll preface this with an acknowledgement that once again, the sensor components are really helpful. So they have a lot of context with this stuff. But being able to do things like, see an executable that I'm not expecting running on a machine. and then go back into the packet captures from the sensor and see where exactly that device came from,

what the user was up to. 99% of the time, it's something that was just being executed, surrounded by a whole bunch of encrypted Gmail traffic. They're also always checking their home email address and pointing out something nasty from there. But it's really a good sort of jumping off point for the threat of the stuff. It's not an all-in-one solution, but it's a good winnowing process for taking the staggering amount of logs that we all have and sort of bubbling the big issues up to the top. Specific stuff that I was particularly interested in and I used to use it for is group membership changes, the Active Directory, password changes or user enablements

for privileged accounts or service accounts that were doing human things that they shouldn't have met. One of our developers get a service account that has superior privileges and now they're using that rather than wanting to request their IT, that sort of thing. So it's good for just sort of keeping everyone honest and making sure that we just follow the proper procedure. So in those use case scenarios, you would create dashboards that would keep trend analysis information. So show the top accounts locked out of being attempted or the top users that are authenticating with you. Is that kind of what I'm doing? Right, right. A lot of that stuff I would do for longer term analysis through a lot

of parser studio product. Again, that allows you to take a directory full of event logs and basically run a SQL query account. I say, okay, kick out everything with this event ID. So if I'm looking for failed logins, for example, I say, okay, give me all the failed logins, pull out the timestamp that had happened, the username, what DC they were authenticating against. We'll spit all that out into a CSV, and I can put that into Power BI Desktop and say, okay, show me a dashboard. Show me a graph of which accounts were logged in, you know, which