WEBVTT 1 00:00:00.040 --> 00:00:02.560 Welcome to a deep dive that's all about making complex 2 00:00:02.600 --> 00:00:08.160 cybersecurity concepts clear and intensely practical. Absolutely, today we're unpacking 3 00:00:08.199 --> 00:00:13.039 a fascinating topic, security monitoring. With Wazoo. You've provided us 4 00:00:13.080 --> 00:00:16.600 with a fantastic resource, really and a comprehensive look at 5 00:00:16.600 --> 00:00:20.359 this powerful open source security platform, and our mission today 6 00:00:20.399 --> 00:00:23.079 is to distill its most important nuggets, giving you a 7 00:00:23.120 --> 00:00:26.719 comprehensive understanding of its capabilities and how it tackles critical 8 00:00:26.800 --> 00:00:28.440 cybersecurity challenges head on. 9 00:00:28.879 --> 00:00:32.679 Yeah, and what's truly compelling about Wazuo, particularly as an 10 00:00:32.719 --> 00:00:35.439 open source solution, is how directly it confronts some of 11 00:00:35.479 --> 00:00:39.719 the biggest hurdles in cybersecurity today. I mean, I think cost, flexibility, 12 00:00:39.759 --> 00:00:43.439 and the power of community collaboration. It's quite unique. We're 13 00:00:43.439 --> 00:00:47.600 going to explore how it fundamentally enhances threat detection, incident response, 14 00:00:47.640 --> 00:00:52.679 continuous security monitoring, threat intelligence, and compliance management, all consolidated 15 00:00:52.719 --> 00:00:54.759 within a single accessible platform. 16 00:00:54.960 --> 00:00:58.520 So consider this your essential shortcut to understanding how you 17 00:00:58.560 --> 00:01:02.920 can get hands on with crucial cybersecurity skills, whether you're 18 00:01:02.920 --> 00:01:05.519 just stepping into the field or maybe you're looking to 19 00:01:05.680 --> 00:01:09.680 quickly grasp the cutting edge of modern security operations. Okay, 20 00:01:09.719 --> 00:01:13.159 let's unpack this. Then, the material we have highlights Wazoo 21 00:01:13.359 --> 00:01:14.640 as a real game changer. 22 00:01:14.799 --> 00:01:15.480 It really is. 23 00:01:15.560 --> 00:01:18.560 Beyond just being open source. What are the core benefits 24 00:01:18.599 --> 00:01:23.239 that truly elevate it in today's constantly evolving cybersecurity landscape. 25 00:01:23.319 --> 00:01:26.560 Well, the profound benefits of Wazoo, they really distill down 26 00:01:26.599 --> 00:01:30.319 to two core pillars flexibility and cost effectiveness. Okay, because 27 00:01:30.319 --> 00:01:35.359 it's open source, organizations gain this unparalleled freedom to adapt 28 00:01:35.359 --> 00:01:38.079 its source code engine your new features tailored to their 29 00:01:38.159 --> 00:01:42.239 unique needs, and seamlessly integrate it deeply within their existing 30 00:01:42.319 --> 00:01:47.159 security ecosystem. Its configuration is incredibly granular, you know how, 31 00:01:47.319 --> 00:01:51.079 allowing for precise tuning to meet specific, often quite niche 32 00:01:51.239 --> 00:01:54.760 security requirements. And then on the cost side, well, the 33 00:01:54.799 --> 00:01:58.439 absence of software license fees and vendor lock in genuinely 34 00:01:58.480 --> 00:02:02.079 democratizes access to advanced cybersecurity capability. 35 00:02:02.159 --> 00:02:04.280 Right, no lock in. That's huge, exactly. 36 00:02:04.760 --> 00:02:08.719 This makes sophisticated protection accessible to a much broader spectrum 37 00:02:08.759 --> 00:02:12.759 of users, and equally important, it serves as an invaluable 38 00:02:12.840 --> 00:02:15.680 educational resource for anyone looking to learn hands on. 39 00:02:16.240 --> 00:02:19.280 That accessibility is more than just a benefit. It feels 40 00:02:19.319 --> 00:02:23.439 like a massive shift for democratizing powerful security tools. I 41 00:02:23.439 --> 00:02:26.120 think so too so for someone looking to get hands 42 00:02:26.120 --> 00:02:28.879 on with this, what's actually under the hood? Could you 43 00:02:28.879 --> 00:02:31.879 walk us through the fundamental architecture? How do these parts interact? 44 00:02:32.000 --> 00:02:35.719 Sure? So, the waz solution operates through a synergistic arrangement 45 00:02:35.759 --> 00:02:39.080 of three primary components plus its agents of course, okay. 46 00:02:39.319 --> 00:02:41.599 At the core is the Wazuo server. Think of it 47 00:02:41.599 --> 00:02:45.280 as the central brain. It meticulously collects logs from diverse 48 00:02:45.319 --> 00:02:50.240 sources I mean everything, endpoints, network infrastructure, firewalls, cloud instances, 49 00:02:50.360 --> 00:02:53.800 all of it, all of it, and crucially, it normalizes 50 00:02:53.840 --> 00:02:57.919 this disparate data into a uniform format before analysis. It 51 00:02:57.960 --> 00:03:01.840 also exposes an API for remote interaction and management. Then 52 00:03:01.879 --> 00:03:05.319 we have the Wazoo Indexer. This is designed specifically for 53 00:03:05.479 --> 00:03:09.000 indexing and robustly storing all the security alerts generated by 54 00:03:09.000 --> 00:03:12.840 the server. It's engineered to handle colossal volumes of data, 55 00:03:12.919 --> 00:03:15.360 ensuring scalability even in high demand environments. 56 00:03:15.479 --> 00:03:16.199 Don't grow with you. 57 00:03:16.319 --> 00:03:20.240 Precisely, your window into all this activity is the Wazoo dashboard. 58 00:03:20.360 --> 00:03:24.759 This is your web interface. Pretty intuitive provides comprehensive visualization 59 00:03:24.840 --> 00:03:28.360 and analysis capabilities. You can monitor events craft custom rules 60 00:03:28.400 --> 00:03:35.479 and critically track regulatory compliances across standards like pcidss GDPR HIPITA, 61 00:03:36.000 --> 00:03:39.680 NIST eight hundred and fifty three. All that alongside detecting 62 00:03:39.719 --> 00:03:40.919 vulnerable applications. 63 00:03:41.080 --> 00:03:42.639 Wow, okay, compliance too. 64 00:03:42.800 --> 00:03:46.199 Yeah. And finally, the Wazoo agents. These are the eyes 65 00:03:46.240 --> 00:03:48.479 and ears on the ground right right. They're installed directly 66 00:03:48.479 --> 00:03:51.400 on the endpoints you want to monitor, servers, desktops, laptops, 67 00:03:51.400 --> 00:03:55.360 cloud vms. These agents leverage the oseecid module to collect 68 00:03:55.439 --> 00:03:58.280 real time events and transmit them securely back to the server. 69 00:03:58.240 --> 00:04:01.560 The ossec module. Okay, if I'm understanding this correctly, it's 70 00:04:01.599 --> 00:04:04.879 capable of monitoring everything from my individual laptop all the 71 00:04:04.879 --> 00:04:07.639 way up to an entire cloud infrastructure. That's it. That's 72 00:04:07.719 --> 00:04:12.280 remarkable versatility for a single platform. And how do organizations 73 00:04:12.280 --> 00:04:15.919 typically go about deploying something with this kind of breadth? 74 00:04:16.120 --> 00:04:16.839 Is it complex? 75 00:04:17.240 --> 00:04:20.920 Well? Wazoo is designed with deployment flexibility in mind. You 76 00:04:20.959 --> 00:04:24.680 can implement it on premises within various cloud environments, or 77 00:04:24.720 --> 00:04:28.079 containerize using technologies like Docker and Kubernetes. 78 00:04:28.279 --> 00:04:29.959 Lots of options okay, for. 79 00:04:29.959 --> 00:04:34.519 Production grade resilience and to manage substantial traffic deploying components 80 00:04:34.519 --> 00:04:37.800 in a cluster configuration is strongly recommended, you know, for. 81 00:04:37.800 --> 00:04:40.199 High availabilities make sense for production, but for. 82 00:04:40.199 --> 00:04:44.319 A more streamlined learning or lab environment. There's a convenient 83 00:04:44.399 --> 00:04:49.360 Wazoo VMOVA file that unifies all components into one easy 84 00:04:49.399 --> 00:04:52.399 to deploy package, simplifies setup. 85 00:04:52.079 --> 00:04:55.480 Immensely as handy for getting started definitely okay. That truly 86 00:04:55.480 --> 00:04:58.639 gives us a solid foundation for understanding Wazoo's architecture. Now, 87 00:04:58.720 --> 00:05:01.399 let's get into the heart of its power. What can 88 00:05:01.439 --> 00:05:02.920 Wazoo actually do? Ah? 89 00:05:02.959 --> 00:05:03.600 The fun part. 90 00:05:03.680 --> 00:05:07.519 Our source material meticulously breaks down its core capabilities, beginning 91 00:05:07.560 --> 00:05:11.240 with its role as an intrusion detection system or IDs. 92 00:05:11.000 --> 00:05:15.639 Right, and IDs is absolutely fundamental in cybersecurity. Its primary 93 00:05:15.720 --> 00:05:19.160 role is to continuously monitor network traffic, system logs other 94 00:05:19.199 --> 00:05:23.519 critical information streams, basically looking for patterns patterns that signal 95 00:05:23.639 --> 00:05:27.199 known threats or anomalist behaviors. Its ultimate purpose is to 96 00:05:27.240 --> 00:05:31.439 alert security administrators promptly to potential threats or outright breaches. 97 00:05:31.639 --> 00:05:34.600 And when we talk about IDs, there are different categories, right, 98 00:05:34.600 --> 00:05:35.600 It's not just one type. 99 00:05:35.759 --> 00:05:40.480 Precisely, we categorize them broadly into network contrusion detection systems NIDS, 100 00:05:40.560 --> 00:05:43.079 which primarily monitor network traffic at a broader. 101 00:05:42.879 --> 00:05:44.720 Level like the whole network highway. 102 00:05:44.519 --> 00:05:48.160 Kind of yeah, and a host intrusion detection systems HIDS 103 00:05:48.480 --> 00:05:53.160 which focus on monitoring individual devices, individual endpoints. Wazoo itself 104 00:05:53.199 --> 00:05:56.439 is prominently recognized as a powerful HIDS. 105 00:05:56.560 --> 00:05:59.240 Okay, so Wazoo is mainly at HIDS. But here's where 106 00:05:59.240 --> 00:06:02.439 it gets really interesting for me the mention of suri 107 00:06:02.519 --> 00:06:06.720 Kata in our source. Ah. Yes, what exactly is suri 108 00:06:06.800 --> 00:06:10.319 Kata and how does it integrate with Wazoo to enhance 109 00:06:10.319 --> 00:06:12.079 the overall detection capabilities. 110 00:06:12.240 --> 00:06:17.079 So, Sirakata is a highly capable open source network IDSES. 111 00:06:17.639 --> 00:06:21.199 It excels at monitoring network traffic in real time. It 112 00:06:21.319 --> 00:06:24.439 uses a sophisticated rule based language to detect a wide 113 00:06:24.519 --> 00:06:29.319 array of threats, malware intrusion, attempts, subtle network anomalies. 114 00:06:30.040 --> 00:06:32.560 It's very powerful dy essex so it can block too. 115 00:06:32.680 --> 00:06:37.279 It can yes the IPS part intrusion prevention system. Organizations 116 00:06:37.319 --> 00:06:40.279 deploy it for its network traffic visibility, its ability to 117 00:06:40.319 --> 00:06:44.160 perform signature and anomaly detection against robust community rule sets 118 00:06:44.240 --> 00:06:48.759 like emerging threats, and its deep protocol analysis capabilities. While 119 00:06:48.759 --> 00:06:51.800 it can function as an IPS to actively block malicious traffic. 120 00:06:52.160 --> 00:06:57.040 That capability requires really meticulous configuration to avoid disrupting legitimate operations. 121 00:06:57.079 --> 00:06:58.519 You have to be careful, right, You don't want to 122 00:06:58.519 --> 00:07:01.160 block the wrong thing exactly, So, how does this combination 123 00:07:01.360 --> 00:07:04.800 Wazoo and Sirikata manifesting catching actual threats? Can you walk 124 00:07:04.879 --> 00:07:07.480 us through some tangible examples from the source material. 125 00:07:07.600 --> 00:07:11.519 Absolutely, the examples truly brant to life. Consider network scanning 126 00:07:11.560 --> 00:07:12.439 prob attack detection. 127 00:07:12.560 --> 00:07:13.800 Okay, like end map scans. 128 00:07:14.120 --> 00:07:17.399 Exactly if an attacker attempts an n MAP syn scan 129 00:07:17.560 --> 00:07:20.160 or maybe a version scan on a target machine, the 130 00:07:20.199 --> 00:07:24.079 source material demonstrates how Surikata, powered by the Emerging Threats 131 00:07:24.160 --> 00:07:28.360 rules set, will immediately detect this. Wazoo then visualizes these 132 00:07:28.399 --> 00:07:32.480 alerts on its dashboard. You see crucial details like ET scan, 133 00:07:32.600 --> 00:07:36.439 potential SSH scan outbound or n MAP scan alerts, complete 134 00:07:36.480 --> 00:07:39.560 with the attacker source IP and the detected signature. That 135 00:07:39.720 --> 00:07:41.240 granular detail. 136 00:07:40.920 --> 00:07:42.720 Is vital instant visibility. 137 00:07:42.879 --> 00:07:46.519 Right. Then there are web based attacks using DVWA, the 138 00:07:46.680 --> 00:07:51.240 damn vulnerable web application that intentional insecure environment used for 139 00:07:51.319 --> 00:07:52.079 training and testing. 140 00:07:52.160 --> 00:07:54.160 I yes, DVWA classic. 141 00:07:54.399 --> 00:07:58.079 The source illustrates how Surricata effectively identifies common web attacks 142 00:07:58.160 --> 00:08:02.079 like SQL injection and reflected cross scripting or EXSS okay 143 00:08:02.120 --> 00:08:04.800 show me. For instance, in SQL injection example might involve 144 00:08:04.839 --> 00:08:08.040 an attacker injecting something like union select hello Hello again 145 00:08:08.360 --> 00:08:12.399 into a URL. Sirrakata flags this instantly as e tech 146 00:08:12.519 --> 00:08:16.439 webserver possible SQL injection attempt, and WASO highlights the specific 147 00:08:16.759 --> 00:08:19.000 URL query string used in the attack right there on. 148 00:08:19.000 --> 00:08:21.800 The dashboard, so you see exactly what they tried Precisely. 149 00:08:22.680 --> 00:08:27.439 Similarly, for a reflected EXSS example, injecting a script tag 150 00:08:27.600 --> 00:08:31.439 like script alert exss script is immediately flagged by Sirakata 151 00:08:31.480 --> 00:08:36.480 as et webserver script tag in URI cross site scripting attempt. 152 00:08:36.720 --> 00:08:39.919 Those examples really paint a picture of how granular this 153 00:08:40.039 --> 00:08:43.519 detection can be. It's not just something happened, it's what happened. 154 00:08:43.720 --> 00:08:47.519 That's the key takeaway for an organization. The implications seemed profound. 155 00:08:48.080 --> 00:08:50.919 What's the biggest shift in security posture this kind of 156 00:08:51.000 --> 00:08:52.679 detailed visibility enables. 157 00:08:53.000 --> 00:08:56.360 Well. The real revelation here is how Surikata, combined with 158 00:08:56.399 --> 00:09:02.440 Wazu's visualization, transforms raw network activity into immediate actionable intelligence. 159 00:09:02.879 --> 00:09:05.720 It's not just about detecting an end map scan. It's 160 00:09:05.720 --> 00:09:08.600 about getting the attacker's IP and the specific signature in 161 00:09:08.639 --> 00:09:12.639 an instant. This capability dramatically cuts down investigation time. We're 162 00:09:12.639 --> 00:09:14.159 talking hours down to minutes. 163 00:09:14.279 --> 00:09:14.840 That's huge. 164 00:09:14.919 --> 00:09:18.919 It empowers rapid response, preventing minor probes from potentially escalating 165 00:09:19.000 --> 00:09:22.399 into major incidents. It really shifts you towards proactive defense, 166 00:09:22.480 --> 00:09:24.399 not just reactive cleanup, proactive. 167 00:09:24.480 --> 00:09:29.399 I like that. Okay, So beyond intrusions, malware remains this pervasive, 168 00:09:29.519 --> 00:09:35.000 constantly evolving threat. How does Wazo specifically help in combating 169 00:09:35.039 --> 00:09:36.200 this persistent challenge. 170 00:09:36.279 --> 00:09:39.000 Yeah, malware, as you know, it's incredibly diverse. You've got 171 00:09:39.120 --> 00:09:42.799 viruses attaching to files like I Love You, worms spreading 172 00:09:42.840 --> 00:09:45.519 through networks like my Doom. 173 00:09:44.960 --> 00:09:47.399 My Doom Wow, blasts from the past, right. 174 00:09:47.720 --> 00:09:52.039 Then trojans disguise as legitimate software like zeus, ransomware encrypting 175 00:09:52.120 --> 00:09:55.840 data WannaCry being a famous example, and stealthy spyware like 176 00:09:55.879 --> 00:09:59.279 fin spy covertly collecting info. It's a vast landscape. 177 00:09:59.320 --> 00:10:02.159 That's an enormous range of threats to constantly monitor and 178 00:10:02.200 --> 00:10:02.919 defend against. 179 00:10:03.039 --> 00:10:06.679 Seems overwhelming, it can be, but Wazoo has robust building 180 00:10:06.759 --> 00:10:10.720 capabilities and crucial integrations to tackle this. File integrity monitoring 181 00:10:10.840 --> 00:10:13.279 FM is absolutely foundational. 182 00:10:12.720 --> 00:10:15.000 Here fem okay, how does that work? 183 00:10:15.159 --> 00:10:18.679 Wazoo leverages FEM to detect any changes, additions, or deletions 184 00:10:18.720 --> 00:10:22.679 to critical system files think executables, canfig files, temp files, 185 00:10:22.720 --> 00:10:26.200 register re entries, even PowerShell scripts. If malware attempts to 186 00:10:26.279 --> 00:10:29.679 modify or create a suspicious file, FM instantly triggers an 187 00:10:29.720 --> 00:10:30.879 alert BAM, so. 188 00:10:30.840 --> 00:10:33.559 It spots unauthorized changes immediately exactly. 189 00:10:34.039 --> 00:10:37.440 Additionally, its root kit behavior detection uses the root check function. 190 00:10:38.240 --> 00:10:41.600 This looks for anomalies that strongly suggest a root kit's presence, 191 00:10:41.639 --> 00:10:45.840 things like unauthorized privileged escalation or attempts to conceal malicious 192 00:10:45.840 --> 00:10:46.960 files or processes. 193 00:10:47.039 --> 00:10:51.519 Root check got it. Now. We've explored Wazoo's native capabilities, 194 00:10:51.919 --> 00:10:54.840 but in modern security, integration is key. 195 00:10:54.799 --> 00:10:55.919 Right, absolutely critical. 196 00:10:56.080 --> 00:10:59.080 How does Wazoo extend its reach by working with external 197 00:10:59.120 --> 00:11:02.240 tools and what are some of the most impactful integrations 198 00:11:02.240 --> 00:11:03.200 for malware detection? 199 00:11:03.480 --> 00:11:06.840 Yeah, the beauty of Wazoo lies in its extensibility. One 200 00:11:06.919 --> 00:11:11.720 powerful method involves CDB lists constant database files. CDB list 201 00:11:11.840 --> 00:11:15.039 basically simple text files. Wazu can use these to store 202 00:11:15.159 --> 00:11:18.399 curated lists of known malware hashes like md fives or 203 00:11:18.440 --> 00:11:21.639 suspicious ips and domains. If a file's hash on a 204 00:11:21.679 --> 00:11:24.879 monitored endpoint matches an entry in say a malware hash 205 00:11:24.960 --> 00:11:28.279 is CDB list, Wazu immediately triggers an alert. The material 206 00:11:28.320 --> 00:11:31.360 gets a clear example of detecting a Mira malware file. 207 00:11:31.480 --> 00:11:32.919 This way simple but effective. 208 00:11:33.159 --> 00:11:36.600 Very Then there's the incredibly powerful Virus Total Integration. 209 00:11:36.279 --> 00:11:38.720 AH Virus Total. Everyone knows that one right. 210 00:11:39.039 --> 00:11:42.360 Wazu's FEM module can monitor a specific directory and when 211 00:11:42.360 --> 00:11:45.679 a file changes, it automatically sends that files hash to 212 00:11:45.799 --> 00:11:49.919 Virus Total for comprehensive analysis. Virus Total then stands it 213 00:11:49.960 --> 00:11:53.200 with over seventy different anti virus engines, giving you this 214 00:11:53.360 --> 00:11:57.799 multifaceted assessment. We saw compelling example detecting an ICAR test 215 00:11:57.840 --> 00:11:58.320 file with. 216 00:11:58.320 --> 00:12:01.559 This seventy engines. That's thorough it is. 217 00:12:02.080 --> 00:12:06.480 Wazoo also facilitates Windows Defender logs integration. Now, while Defender 218 00:12:06.519 --> 00:12:11.240 is ubiquitous, Wazoo can centralize its logs. This gives SoC analysts, 219 00:12:11.240 --> 00:12:14.320 you know, security operation center analysts, a unified view of 220 00:12:14.480 --> 00:12:18.720 endpoint security status directly from the Wazoo manager streamlining oversight. 221 00:12:18.879 --> 00:12:20.759 Okay, unifying the view. That's helpful. 222 00:12:20.879 --> 00:12:24.000 And this brings up an important question. What about sophisticated 223 00:12:24.039 --> 00:12:28.200 threats like filess malware. These attacks don't leave traditional files 224 00:12:28.200 --> 00:12:30.279 on disc, making them incredibly evasive. 225 00:12:30.360 --> 00:12:33.600 Yeah, that's notoriously tricky for traditional security tools. How does 226 00:12:33.679 --> 00:12:37.200 Wazoo approach detecting those kinds of stealthy attacks. 227 00:12:37.519 --> 00:12:41.720 Well, fileust malware operates primarily in memory, leveraging legitimate system 228 00:12:41.759 --> 00:12:45.159 processes and tools. That's precisely why traditional file based anti 229 00:12:45.240 --> 00:12:46.320 virus solutions. 230 00:12:45.919 --> 00:12:48.279 Struggle, right, nothing to scan on the desk exactly. 231 00:12:48.519 --> 00:12:52.080 This is where sisman becomes indispensable. Sisman is a Windows 232 00:12:52.080 --> 00:12:56.360 system service provides incredibly advanced detailed monitoring of process creation, 233 00:12:56.840 --> 00:13:00.919 network connections, file changes much deeper than standard logs. 234 00:13:01.039 --> 00:13:05.639 So sisman creates this deep, granular log of intricate system activities, 235 00:13:06.320 --> 00:13:10.600 and Wazoo then ingests and analyzes those logs to spot 236 00:13:10.639 --> 00:13:15.080 the subtle, non file based indicators of fileless attacks, things 237 00:13:15.120 --> 00:13:19.240 like unusual process injection, suspicious network connections from trusted processes, 238 00:13:19.720 --> 00:13:23.360 or maybe specific stealthy registry modifications for persistence. 239 00:13:23.440 --> 00:13:26.799 Precisely, you've got it the source material meticulously breaks down 240 00:13:26.840 --> 00:13:31.679 fileless malware attacks into their common stages, gain access, deal credentials, 241 00:13:32.039 --> 00:13:36.639 establish persistence, often through registry manipulation, and finally data exfiltration. 242 00:13:37.360 --> 00:13:41.600 Sisman's highly detailed logging, when seamlessly integrated with Wazoo, is 243 00:13:41.639 --> 00:13:45.200 instrumental in exposing these often hidden activities that conventional file 244 00:13:45.240 --> 00:13:48.960 based detection might entirely miss. It really transforms Wazoo into 245 00:13:48.960 --> 00:13:52.039 a much more robust guardian against these modern advanced threats. 246 00:13:52.240 --> 00:13:57.960 That integration sounds crucial for dealing with modern attack techniques. Okay, 247 00:13:57.960 --> 00:14:03.720 shifting gear slightly. In cybersecurity, we're constantly bombarded and overwhelming 248 00:14:03.720 --> 00:14:07.919 influx of new threats, vulnerabilities, indicators of compromise. The noise 249 00:14:07.960 --> 00:14:12.039 is incredible sometimes exactly how does Wazu help security teams 250 00:14:12.120 --> 00:14:14.679 make sense of this dayly age of information and turn 251 00:14:14.720 --> 00:14:18.000 it into actionable intelligence rather than just noise. 252 00:14:18.360 --> 00:14:22.399 This is precisely where automated threat intelligence transitions from being 253 00:14:22.440 --> 00:14:25.559 a nice to have to an absolute necessity. I mean, 254 00:14:25.879 --> 00:14:29.519 the days of manually copying and pasting thousands of observable 255 00:14:29.600 --> 00:14:34.639 suspicious IPS hashes into various databases are just inefficient, unsustainable 256 00:14:35.279 --> 00:14:38.399 Automated threat intelligence is designed to directly address the critical 257 00:14:38.440 --> 00:14:42.679 challenges delayed detection, missed alerts, sluggish response times that plague 258 00:14:42.720 --> 00:14:43.840 manual processes. 259 00:14:44.080 --> 00:14:46.879 So what are the cornerstone tools that Wazoo integrates with 260 00:14:47.000 --> 00:14:49.279 to achieve this level of automated threat intelligence. 261 00:14:49.519 --> 00:14:53.480 Wazu integrates with some really powerful and widely adopted platforms 262 00:14:53.480 --> 00:14:56.960 in the industry. Think MISP, the malware information Sharing platform 263 00:14:57.000 --> 00:14:59.960 and ASP right the Hive, which is a robust, oh 264 00:15:00.000 --> 00:15:04.159 open source incident management platform, and Cortex, a potent threat 265 00:15:04.200 --> 00:15:06.600 analysis engine that works hand in hand with the Hive. 266 00:15:06.879 --> 00:15:12.320 Okay, MISP, the Hive Coretex. What are the compounding benefits 267 00:15:12.360 --> 00:15:15.639 of linking all these together within the Wazoo ecosystem. 268 00:15:15.799 --> 00:15:19.879 The integration delivers several profound benefits. First, it enables scalable 269 00:15:19.919 --> 00:15:24.759 security operations. By streamlining how security events are handled, organizations 270 00:15:24.799 --> 00:15:28.240 can effectively manage an ever increasing volume of incidents with 271 00:15:28.360 --> 00:15:32.480 significantly less manual effort. Teams can scale without just throwing 272 00:15:32.480 --> 00:15:33.200 more people. 273 00:15:32.960 --> 00:15:35.120 At the problem. Efficiency games big time. 274 00:15:35.399 --> 00:15:39.600 Second, it facilitates automated incident response by directly leveraging the 275 00:15:39.720 --> 00:15:43.320 rich threat intelligence data from MISP analysts within the Hive 276 00:15:43.360 --> 00:15:47.080 can rapidly generate consistent prompt response playbooks. This ensures every 277 00:15:47.159 --> 00:15:50.000 identified incident is addressed with speed and precision. 278 00:15:49.960 --> 00:15:52.360 So standardizing the response. Can you give us a concrete 279 00:15:52.399 --> 00:15:56.360 example of this entire chain in action, Wazoo, MISP, the 280 00:15:56.440 --> 00:15:57.799 Hive Cortex working together. 281 00:15:57.879 --> 00:16:00.799 Yeah, the source material provides an excellent use case. Imagine 282 00:16:00.799 --> 00:16:03.919 Wazoo generates a critical alert. That alert is automatically sent 283 00:16:03.960 --> 00:16:04.440 to the hive. 284 00:16:04.759 --> 00:16:06.679 Okay, alert pops up in the hive right. 285 00:16:07.039 --> 00:16:10.240 An SC analyst reviews this alert in the hive, creates 286 00:16:10.240 --> 00:16:12.759 a new case and adds various observables that are part 287 00:16:12.759 --> 00:16:15.840 of the alert, maybe a suspicious file name like sv 288 00:16:16.000 --> 00:16:19.440 cost dot ex, a problematic IP address like ninety five 289 00:16:19.440 --> 00:16:25.879 point one four, or a malicious domain like drivogle, dot firewalldush, gateway, 290 00:16:25.919 --> 00:16:26.399 dot com. 291 00:16:26.480 --> 00:16:27.960 Okay, collecting the clues. 292 00:16:27.679 --> 00:16:30.919 Exactly, and then the Hive, through its integration with Cortex, 293 00:16:31.279 --> 00:16:37.080 analyzes those specific observables against comprehensive MISP threat intelligence feeds. 294 00:16:36.879 --> 00:16:41.080 Ah so Cortex queries MISP. That's where the magic happens exactly. 295 00:16:41.240 --> 00:16:44.600 The analyst can initiate an analyzer maybe MISP twenty one 296 00:16:44.759 --> 00:16:47.759 directly on the observable within the hive. The hive then 297 00:16:47.799 --> 00:16:51.399 receives a detailed report back from MISP. This report outlines 298 00:16:51.440 --> 00:16:55.279 any matching threat intelligence events, including critical info like evn IDs, 299 00:16:55.399 --> 00:16:58.480 the original source providers of the intel like circole. This 300 00:16:58.519 --> 00:17:01.519 process dramatically enriches the analysts understanding. 301 00:17:01.080 --> 00:17:03.039 Provides context instantly. 302 00:17:02.600 --> 00:17:05.319 Right immediate context. It helps them assess the severity and 303 00:17:05.440 --> 00:17:08.000 nature of the attack far more quickly than manual lookups. 304 00:17:08.000 --> 00:17:10.759 Ever, could that sounds like an absolute game changer for 305 00:17:10.799 --> 00:17:14.440 security teams. Yeah, a massive productivity boost automating that initial 306 00:17:14.440 --> 00:17:15.880 investigation and enrichment. 307 00:17:16.000 --> 00:17:16.559 It really is. 308 00:17:16.680 --> 00:17:20.079 Okay, building on that concept of automated threat intelligence and 309 00:17:20.200 --> 00:17:27.200 incident enrichment, let's talk sor security orchestration, automation and response. 310 00:17:27.359 --> 00:17:29.599 Sounds like something right out of a sci fi movie. Yeah, 311 00:17:29.599 --> 00:17:34.680 you know, autonomous defense systems. What exactly is SR in 312 00:17:34.720 --> 00:17:38.400 simple terms? And how does it push security operations forward? 313 00:17:38.680 --> 00:17:43.720 Well? Gardner defines SR as solutions that combine incident response, orchestration, automation, 314 00:17:44.039 --> 00:17:48.400 and threat intelligence management into a single, unified platform. Its 315 00:17:48.440 --> 00:17:52.039 overarching purpose is to implement security playbooks and workflows that 316 00:17:52.160 --> 00:17:56.440 actively support analysts moving beyond just alerting to active mitigation 317 00:17:56.559 --> 00:17:57.160 and response. 318 00:17:57.279 --> 00:18:00.160 Okay, break that down a bit orchestration automation. 319 00:18:00.000 --> 00:18:04.119 Sure security orchestration is about coordinating tasks across multiple disparate 320 00:18:04.200 --> 00:18:08.480 tools and teams, making them work together harmoniously like a conductor. 321 00:18:08.759 --> 00:18:12.599 Security automation is the execution of predefined actions in response 322 00:18:12.640 --> 00:18:16.880 to specific security events, often without direct human intervention at that. 323 00:18:16.920 --> 00:18:19.119 Moment, machines doing the work to a degree. 324 00:18:19.240 --> 00:18:23.720 Yes, An incident response within SR is about systematically streamlining 325 00:18:23.720 --> 00:18:27.720 the entire process from detection through containment and recovery when 326 00:18:27.720 --> 00:18:28.759 an incident occurs. 327 00:18:28.960 --> 00:18:31.359 So it connects all the pieces and makes them act 328 00:18:31.599 --> 00:18:35.839 autonomously or at least automatically initiate actions based on playbooks. 329 00:18:36.079 --> 00:18:39.160 What's an example of an open source SR platform that 330 00:18:39.200 --> 00:18:40.799 integrates effectively with Wazoo. 331 00:18:41.000 --> 00:18:45.599 Our source introduces shuffle Soar. It's an open source interpretation 332 00:18:45.759 --> 00:18:49.680 of SR principles, leveraging Docker and micro services for its architecture. 333 00:18:50.079 --> 00:18:53.400 It features highly customizable apps and workflows, enabling users to 334 00:18:53.480 --> 00:18:58.319 construct bespoke security use cases typically categorized into stages collect 335 00:18:58.359 --> 00:19:00.480 and rich, detect, respond and verify. 336 00:19:00.799 --> 00:19:03.480 Very modular Shuffle so and how does the integration between 337 00:19:03.519 --> 00:19:05.640 Wazoo and Shuffle actually work in practice. How do they 338 00:19:05.640 --> 00:19:06.440 talk well? 339 00:19:06.440 --> 00:19:09.880 The initial integration scripts are conveniently pre built within Wazoo, 340 00:19:09.880 --> 00:19:14.279 which helps. Yeah. The process involves creating a Shuffle workflow 341 00:19:14.319 --> 00:19:17.839 with a specific webook URI. Then you configure Wazoo to 342 00:19:17.880 --> 00:19:21.359 push relevant alerts say all alerts above level three or 343 00:19:21.400 --> 00:19:24.519 specifical ideas like five hundred and ten for abnormal logins 344 00:19:24.519 --> 00:19:27.799 directly to that web hook. This allows Shuffle to ingest 345 00:19:27.839 --> 00:19:30.480 security events from Wazoo and then act upon them based 346 00:19:30.480 --> 00:19:31.920 on its configured workflows. 347 00:19:32.000 --> 00:19:35.079 Okay, so Wazoo pushes alerts to Shuffle. This raises an 348 00:19:35.079 --> 00:19:39.920 important question though, Can Shuffle actually control Wazoo? Can it 349 00:19:39.960 --> 00:19:41.960 reach back and tell Wazuo to do something? 350 00:19:42.079 --> 00:19:44.400 Yes, it absolutely can, and this is where the power 351 00:19:44.400 --> 00:19:47.519 of USAW really comes to life. Shuffle can remotely manage 352 00:19:47.559 --> 00:19:50.839 waz by authenticating to the Wazu API. You first get 353 00:19:50.839 --> 00:19:54.160 a JWT adjacent web token from Wazoo for secure access, 354 00:19:54.599 --> 00:19:57.559 and then use that token to make subsequent API requests. 355 00:19:57.720 --> 00:20:01.559 This enables Shuffle to programmatically add, remove, restart, or even 356 00:20:01.640 --> 00:20:04.319 upgrade Wazoo agents directly from within its workflows. 357 00:20:04.319 --> 00:20:06.799 Wow upgrade agents automatically potentially Yes. 358 00:20:06.880 --> 00:20:10.519 This level of control represents a highly sophisticated automation capability 359 00:20:10.799 --> 00:20:14.799 allowing for truly dynamic and responsive security actions based on events. 360 00:20:15.000 --> 00:20:18.359 That's powerful stuff. Okay, so when an attack actually hits 361 00:20:18.720 --> 00:20:21.799 speed is absolutely everything we know? That's critical. How does 362 00:20:21.839 --> 00:20:26.640 Wazu specifically empower organizations to respond to incidents with the 363 00:20:26.720 --> 00:20:28.559 necessary swiftness and efficacy? 364 00:20:28.640 --> 00:20:33.880 Well, incident response I are, it's fundamentally about that immediate identification, mitigation, containment, 365 00:20:34.319 --> 00:20:37.759 and ultimately fixing the root cause of an attack. Our 366 00:20:37.799 --> 00:20:41.640 source material points to widely recognized frameworks like NIST with 367 00:20:41.759 --> 00:20:45.640 four steps and SANDS with six steps. Both provide structured 368 00:20:45.640 --> 00:20:49.720 guides for navigating this critical process. Wazoo's key contribution here 369 00:20:49.920 --> 00:20:52.559 is its active response capability. 370 00:20:52.039 --> 00:20:55.559 Right active response, What precisely does that entail and how 371 00:20:55.599 --> 00:20:57.079 does it help speed things up? 372 00:20:57.400 --> 00:20:59.920 Wazoo Active Response is a mechanism that allows for autumn 373 00:21:00.359 --> 00:21:03.799 predefined actions to be executed directly on monitored endpoints in 374 00:21:03.839 --> 00:21:07.640 real time, triggered by specific security alerts. It leverages a 375 00:21:07.640 --> 00:21:10.240 combination of pre built scripts like netch dot exx for 376 00:21:10.319 --> 00:21:13.359 Windows or firewall drop for Linux, but also supports custom 377 00:21:13.359 --> 00:21:16.200 scripts tailored to an organization's unique needs or environment. 378 00:21:16.519 --> 00:21:20.119 So if a critical security event happens, Wazoo doesn't just alert, 379 00:21:20.559 --> 00:21:24.720 it can potentially take immediate autonomous action to shut down 380 00:21:24.799 --> 00:21:25.680 or contain the threat. 381 00:21:25.759 --> 00:21:29.599 Potentially, yes, and that's the strategic advantage. The system operates 382 00:21:29.599 --> 00:21:31.960 by the Wazoo server issuing an order to the agent 383 00:21:32.000 --> 00:21:35.400 on the endpoint to perform a specific action. This action 384 00:21:35.480 --> 00:21:38.960 is carefully defined within a command block, which is intrinsically 385 00:21:39.039 --> 00:21:42.480 tied to a particular rule ID, a severity level, or 386 00:21:42.559 --> 00:21:45.000 a rule group that has been triggered by whatever event 387 00:21:45.079 --> 00:21:45.680 was detected. 388 00:21:45.759 --> 00:21:50.519 Okay, trigger rule action. Can you provide some tangible, real 389 00:21:50.559 --> 00:21:53.960 world examples from the source material that illustrate this active 390 00:21:53.960 --> 00:21:54.839 response in action? 391 00:21:55.079 --> 00:21:58.960 Sure? Our source material details several critical use cases, for instance, 392 00:21:59.200 --> 00:22:00.440 blocking unauthorized. 393 00:22:00.279 --> 00:22:01.960 SSH access common problem. 394 00:22:02.039 --> 00:22:05.039 Right, If Wazoo detects an attempt to log in using 395 00:22:05.079 --> 00:22:08.000 a non existent user that corresponds to rule ID fifty 396 00:22:08.039 --> 00:22:10.920 seven to ten, it can trigger the firewall drop script 397 00:22:10.960 --> 00:22:14.160 on say an a Buntu agent. This script automatically adds 398 00:22:14.200 --> 00:22:17.920 the attacker's IP address to the IP tables denialist, effectively 399 00:22:17.920 --> 00:22:20.759 blocking them for a specified time out. Maybe sixty seconds. 400 00:22:20.799 --> 00:22:24.400 Maybe longer buys you time stops the brute force exactly. 401 00:22:24.640 --> 00:22:30.039