 So, thanks for coming to our talk. My name is Ryan Pentney, and I'm a research analyst for the vulnerability research team at SourceFire. I'm joined today by my colleague Patrick Mullen, Principal Research Engineer, and we're here to talk to you today about a new open source project that we've been working on called Razorback. So, Razorback is essentially a new detection and forensics framework, and we're going to talk a little bit more about what it is and how it works in just a second. First, I'd like to sort of outline the formative issues behind its development, as well as talk about some of the problems that it was designed to address. All right, so we've seen in recent years that there has been a shift from a focus on server side exploitation to client side, and it's been made things very, very difficult for defenders. So a lot of client side attacks deal with exploiting vulnerabilities in the software that's responsible for parsing complex file formats or in-browser rendering languages such as JavaScript and Flash. The same complex nature that makes these formats and languages write territory for exploitation presents a variety of challenges for those on the defense side. For one, for a format-aware detection engine to even get to the part of the file, let's say it's examining a file that it's interested in, it must mimic, at least in part, the parsing capabilities of the software program itself. For example, say you're parsing through an office document, and you know that there's a vulnerability in a specific table, and say that the offset of that table in the file is found in another header at another completely different part of that file, your detection software has to be able to first parse up to that header, extract the offset, have collected enough parts of that file to get to where that offset points to, and then look at that field inside that table and compare it against either a fixed value or some other field in the file. That's a rather simple example, but it gets even more complex when you consider the fact that file formats are written by insane people, and they like to do a lot of crazy things with them. This makes things troublesome and performance intensive, especially when you consider how intensively and exhaustively a lot of these detection engines must examine these files and frequently as well. Number two, there are numerous options available at the disposal of the attacker. Many interesting targets with varying degrees of exploitability are available. There are many methods of delivery, so malicious PDF, for instance, can be delivered over mail, can be downloaded over HTTP. Someone could just walk up and hand you a disc with it on it and say, hey, here, look at this. That's another way. Multitude of obfuscation techniques, of course, which can make the same exploit repackageable in different ways, and this makes signature-based approaches and superficial attempts at detection useless. And finally, traditional IDS and IPSs are bound by wire speed. Stream-based reassembly can fall short of full-file reassembly, especially when you're talking about low-latency environments where a detection engine must examine all these files while maintaining multi-gigabit speeds and mimicking the parsing capabilities of hundreds or thousands of client-side machines. So exploits buried in formats that require exhaustive parsing may go undetected at the preservation of speed. So while real-time inspection allows for preventative measures against malicious traffic to be taken, there's also a need to be able to accurately and profoundly profile all traffic regardless of the time cost. Even if it takes a little bit more time to detect, you still want to know what's made it through to your network and what machines are affected. This is where Razorbat comes in. So what we've done here is we've actually taken the functionality of data capture, detection and reporting and split those up. So the cost for a robust and more accurate detection may be that you don't have the option of blocking on something the first time that it's seen, but that might, you're still going to want to know what's on your network, that might not matter anyway. This of course doesn't mean that real-time isn't necessary or useful, it is. On the contrary, real-time analysis is effective at filtering out a majority of attacks. Razorbat simply has a different set of goals. Giving up on most blocking capabilities in exchange for the ability to fully parse data, emulate client machines and provide a more in-depth level of analysis. So a lot of what we sought out to do when we set about developing this was address the needs of many of the analysts and forensics experts who deal with responding and adapting to threats of a more sophisticated nature. You hear this term APT thrown around a lot. Supposedly there are appliances that you can just plug in and are made to, they're designed to block APT. This is kind of a sore point for a lot of us in the industry. APT is not, so what APT really is, is it talks about a level of sophistication and talent. We're talking about people armed with vast resources and knowledge of your network specifically whose goals are not to churn out cookie cutter exploits, but to make inroads into your network and stay there for a very, very long time. So what we developed was a framework that was intended to support analysts in intelligence-driven response, offer up extensible, open and customizable tool to aid in the tasks of forensics, incident response, and threat identification. I'm going to hand it over to Patrick to talk a little bit about the architecture. Right before we get started, I just want to point out that we're going to talk about a lot of things on a very abstract level, so stay with me. We'll begin to a demo where you can see all this stuff in action. Sorry, there we go. There's going to be a demo that will tie us together. At this point it will be a more conceptual piece describing what all the different functions are. So first the framework goals. We really drove this project from the beginning is the question of what would you do with a pointer to data and a size? We really want to make it so that you can have any sort of data from any system come into your system, into the framework, and then be processed in arbitrary ways. It's really scalable. Everything has a very simple, a single task that it does. We'll go into the different types of tasks that we set out for this system. As I said, everything in the system is in a nugget. The nuggets have a very simple, have a single task that they do, and they feed their information to and from the dispatcher to achieve the goals of the greater task. As I said, there are a bunch of different nugget types. We'll talk about each one in a moment. The overall view, as you can see, the dispatcher is what ties everything together. The primary pieces of data or the primary nuggets that we'll talk about that are developed today are the collection nuggets which will gather data. The database which will store all the information. Detection nuggets which will process that data. And we'll have output nuggets that do the alerting and also other types of nuggets that we'll talk about. The dispatcher is the first piece and it's the key piece and what the VRT is supplying as the primary component of Razorback is really the heart of the system. We call it the defense router. It handles all the incoming data, handles all the output data, and also provides mechanisms for correlation nuggets to access the database and do advanced analysis of the data that you have. We also have an API that is developed to make the jobs of the programmers easier so you can make custom nuggets and perform duties that we don't have right now. Okay? It's database driven. A lot of the data that's in there is kind of what you would expect. It has configuration information, of course, the different types of metadata so you can keep track of not only what data is in there and event data, also just kind of why. There's information in there as simple as DNS queries. We'll show later about how a DNS query in itself is not necessarily vulnerability but by doing modeling and analysis of the different types of activities that a host is performing, you can then glean some additional information about that. For example, DNS queries are indicative that the host has been compromised and they are going out to fetch additional payload. Okay? Okay? So as such, because it is a nugget architecture, everything has the same basic architecture where it's talking to the dispatcher and registering and performing the different tasks. We use UUIDs to identify everything because it makes it really easy to add and remove elements from the system depending on what tasks you need. And we'll talk a little bit about what each kind of nugget does. The first one we're going to talk about is a collection nugget. Now, again, what's great about Razorback is that it's a framework. You can use anything. With the collection nuggets, you can use a more traditional thing kind of like what Razorback does and sniff traffic as it goes across the wire. But because the framework allows you to send data to and from the dispatcher using anything, you can actually have agents on your server. You could have an SMTP proxy or a web proxy or be on your mail server itself that will gather data as it comes in and then you don't have to worry about things like lost packs and such. And you can go and talk right to the database. You can also even do more non-traditional pieces of data such as log data or anything else. Whatever kind of information you want to have in your network and use for analysis later, whether it's attack data or just simply, again, keeping an eye on what's going on, you can do a nugget for that. When we talk to the dispatcher, before we do that, we'll actually check a local cache and Ryan will talk about that extensively later just to make sure that we don't have to talk to the dispatcher if we don't have to. You know, we really want to make sure that we don't have to send this data through the network and, you know, take up extra time if we don't need. And if it's not in the local cache, we'll send it to the dispatcher. When it's sent to the dispatcher, it will be sent to the relevant detection nugget. Detection nugget can actually be kind of a generic term. Obviously, there's data and attacks that you look for. But also we have a detection nugget that will do simply take data that's given, split it into logical subcompones to then get sent back to the dispatcher for further analysis by the specialized nuggets. Okay, output nugget. Output nuggets, as you'd expect, provides a user interface or means for providing alerting and other kinds of data to the operator. Whenever an alert is generated, the dispatcher will talk to each of the output nuggets, say that there's an alert available, and then the output nugget, if it decides that it's a type of data that it's interested in, will then ask additional information, as you can see. We try to really split things up, and the one I want to point you out to or point out to you is the normalized data block. If there's some analysis that we do on the data before the alert, say uncompressed some data or de-obvious case of JavaScript, we actually give you access to that. It really doesn't do you a lot of good if we say there's something bad in this file and then you look at it and you're just looking at a compressed data block. It really doesn't give you any information. So we do our best to make sure that the information that you're given is useful and makes the analyst's job much easier. But not every nugget that we have is the simple, bad people doing bad things on the Internet. We also have these intelligence nuggets. Intelligence nuggets are really analysis engines. There are nuggets that provide data that is not necessarily of an alert nature. I mentioned earlier that you can have DNS queries stored. By storing all these DNS queries and seeing that an infected host then goes to all these different hosts as part of continuing its tasks of embedding itself in your network, you can then take a correlation nugget and see that other hosts are doing that same activity. So even though you missed the part where that host was being compromised or maybe it was just compromised long ago, when you see it performing these same exact activities, you can then infer that something bad is going on in that host and go about your cleanup. So does anyone here deal with APT in cleaning up the network after somebody has gone in and owned you up? This right here is really where it makes your job a lot easier. It really is limitless. Like anything you can do, any sort of data mining, this is where it would be done. And what also can be done for correlation nugget is we can talk to a defense update nugget. Defense update nuggets, they're really cool because since we write them or you write them because it's part of the Razorback system, they are completely vendor agnostic. So if you can write a nugget that would not only update multiple devices at once, they can be multiple devices across multiple vendors. An example that I love is that when you realize that you have somebody coming in from the outside and they're trying to go through your network and everything, you could use a defense update nugget to modify your router, redirect them over to a honey net, and then start up some demon loggers to log all their activities. So they'll think that they're going through your network and doing all this terrible stuff, but meanwhile you are analyzing what they're doing, what tools and you're keeping them there longer and while not doing any actual damage and you're able to track them better. And finally we have a workstation nugget, which is simply the interface for analysts within the Razorback system. They can analyze stuff like the configuration files and see all the alerting data. But also another cool thing that we have is the ability for analysts to take events, link them together, and also provide notes. So it makes it so that when one shift is done and they're trying to track people through the network, when the next people take over, or even when you go back in time, I've seen this before, what was it that I did, you can go back and check your notes and get that kind of historical data in a way that's useful. So I'm going to give it back to Ryan and he's going to talk to us about really how they all talk together. All right, so now that we've seen the different pieces of the system, let's take a look at how they work together. All right, so because we designed this as sort of a decentralized distributed framework, all of the different nuggets have to be able to be added and removed fairly easily. And they achieve this via an API function call called registerNugget. And we're going to talk a little bit more about the API a bit later, Patrick will get to that. But for now, just know that it essentially lets the dispatcher know that it exists. So if you've got a detection nugget that comes online, it will have prior knowledge of where the dispatcher is, what its IP port combination is, and call registerNugget, let it know what its IP and port are, what kind of data types it's able to handle, as well as the available number of running threads. That last piece is mostly just for load balancing reasons. But the dispatcher will keep track of all that in its own local routing table. And once it has successfully added each of the different nuggets to the routing table, it sends them back a unique identifier, a nugget ID, which they can then use in all future communications with that dispatcher. All right, so here's an example of data collection in our case. We're looking at web traffic and SMTP traffic. So they come in, the data collector will then take that data and assemble it in such a way that it can be processed. So in the case of downloading a file over HTTP, strip out the headers, reassemble the file, package it up, and ship it off. That collection nugget or data collector will then thread out to the API. We thread out here because we don't want to block on future collection. We want our API to kind of like handle things on the side. So the API will then check it against a local cache of signatures. We have actually two types of caches. We have a cache for signatures, such as MD5 and file size together. We're using MD5 currently, but you can theoretically use any kind of signature that you want. We've also got a local cache of URLs, but if it finds that it hasn't seen that previously, then it will do a remote cache query through the dispatcher, which will then talk to the database and see if the system is a hole or anything, any nugget anywhere on the system has seen it. If that comes back as a cache miss again, and only then is the data actually shipped off to the dispatcher for detection. If we find that that MD5 and file size already exists in the local cache, we can theoretically block immediately, depending on what your type of collection nugget is, what its functions are, what its capabilities are. The dispatcher then, based on the data type, so the collection nugget is essentially responsible for knowing what kind of data that is, ships it off with a specific data type and the dispatcher will then look up in its routing table the set of all nuggets that are able to effectively analyze those data types. We talked about data type, but another kind of type that we keep track of is app type. And app type is the kind of detection that you're doing on a specific data type. So say you've got a nugget that is responsible for in-depth PDF analyzation, and you also have an antivirus nugget. You really want that file to pass to both nuggets because each offers a different kind of piece of the puzzle. If you have two AV nuggets, though, that are registered as the same app type, the dispatcher is smart enough to not do that. It'll avoid redundancy and send the file only once if there's only one unique type of detection that's available. So the dispatcher then ships off the data to the detection nuggets, and the detection nuggets will perform their analysis and give feedback in the form of alert data or detection results. We'll talk a little bit more about that later, too. In this case, we've got a PDF nugget, and in that PDF that it's analyzing, there is a subcomponent of JavaScript. Now, the PDF nugget does not have to be aware of how to parse out that JavaScript. It can effectively take that component, ship that off to the dispatcher, re-enter it into the system, and that data then gets shipped off to another nugget, which is or is incapable of handling that type of data. In this fashion, we can actually break file format, compact file formats down into smaller and smaller parts and address the problem in simpler and simpler ways. All of the detection results, both from the subcomponent and the PDF nugget, are coordinated via something called an event ID, and all that information is stored in our database for later access. Finally, when we've got available alert information, a message is sent from the dispatcher to all available output nuggets, and those output nuggets may or may not be interested in that information. Maybe they're only looking for alert data of a certain format. Maybe they're only looking for alert data for a specific file, but either way, if they're not interested, then they just ignore the message. If they are, then a message is sent back indicating what kind of information they want. Do they want long versions of the data? Do they want normalized data? Do they want the timestamp, the source IP? And if they do, send back that information. Dispatcher packages all that information up for the output nugget. Output nugget then is responsible for formatting it the way that it's designed to do. All right, so we talked a little bit caching. We do this to avoid, as we said, reprocessing files that we don't need to. We can also use it in the case of the local cache for some blocking capabilities. We store MD5 in size, and as I said, you can use theoretically any signature, but that's what we're working with now. The thing is that once you've added a new nugget, a new detection nugget to the system, or you've issued any defense update, then all entries that we previously determined to be good that are cached as good, or we haven't found anything wrong with them, are marked as tainted. You might ask why we mark them as tainted instead of just remove them from the cache altogether. Well, the reason for that is because we can't, not only can we not say for sure that we're 100% confident that those files, according to the new detection, are in fact clean, but say we get another file that matches the MD5 in size or whatever signature that we're using, we can then alert retroactively on any past events. So if we weren't able to detect it with the old detection, we do detect it with the new detection, all past events before that new detection was instituted, we'll trigger an alert. And with that, we're on to the demo, handing it back to Patrick. Try to get the microphone in the right place this time. Okay, so what we're going to do for this example is it's going to be SMTP traffic. We have a PCAP, and that PCAP is an email, the SMTP traffic where somebody is sending an attachment that is a PDF that has an embedded EXE file and that EXE file contains a Trojan. So I really wanted to take the opportunity to show how we can have multiple pieces, each one doing its own special part and providing an alert from that. Okay, so now, stay with me while I hopefully can get the video going, because there's no way that I'm putting five devices all trying to talk together live. Okay. Okay. Okay, so I know there's a lot of information up here in the font's tiny. Don't worry about it. Hopefully people can at least see things scrolling. That's going to be the key part. The actual text doesn't matter, so don't worry that you can't read it. I'll describe what each one of these boxes are and what is being displayed. Okay, so a little bit of a lay of the land. In the top left we have the dispatcher, and that is the piece that handles all the communication between the different components. Each one of the nuggets that are in here will register against the dispatcher, and then the dispatcher will take any data that they generate and send it over to the appropriate component. Okay, in the lower right, that's the SAC, the Snort as a Collector. It's a modified version of Snort that we have where we wrote a preprocessor to gather data. Currently it gathers DNS, web, and SMTP data. It just takes it and packages up the data that we're interested in, sends it to the dispatcher for further analysis. Okay, next in the upper right is SMTP parser. Its job is to take SMTP data that has been collected off the wire, take the SMTP header data, use that as metadata, put that into the database for the correlation information that we were talking about earlier, but also the key part that is relevant to the demo is it will analyze the mail messages, and if there are MIME components, it will split all the MIME components out and send it back to the dispatcher for further analysis. Okay, and in the lower right is the PDF parser. It finds known vulnerabilities in PDFs, but also if it finds embedded objects, such as an EXE file, it will then extract that data, send it back to the dispatcher, and then it'll go to another nugget, such as the one in the middle, which is Clamav. So Clamav has been made into a nugget for our system and provides all the features that Clamav has in nugget form. Oops, play. Okay, right here, we are just showing... This is an interface that was made just to show alert data, just showing that it's clean, there's nothing in the database. Just a moment. Okay, the first thing that's going to happen is the dispatcher is going to be started. That's the one that is in the upper left corner. You can see that it has all the UUIDs of the different types of components that are handled, as well as the different file and data types. And then the next piece that is going to be started is the SMTP parser in the upper right. You can see on the left where the Defense Routing Table on the bottom lists all the nuggets that have been registered, as well as the file type that it handles. Now it's going to start up Clamav. And again, it will update the Defense Routing Table on the left in a moment. There we go. And finally we'll start the PDF parser in the lower right. And now we have a system that is sitting there waiting for data that is available for parsing. Okay, so let's make it do something. On the lower right is the SAC. It is the piece that is reading the PCAP and sending it all through the data. There's a lot that happens right here. So we're going to pause it in the middle of operation so we can talk a little bit about what's going on. And there you go. What's happened so far is the PCAP was read. It has extracted all the SMTP data, sent it over to the dispatcher. The dispatcher says, hey, this is SMTP data. Let's send it over to a handler for this. It goes over to the SMTP parser on the upper right. The SMTP parser extracts all the MIME data, says, oh, there's a PDF file. This needs to be analyzed further. And that gets sent back to the dispatcher. The dispatcher then takes that, actually on the lower left, you can see where the PDF parser has gone through the PDF and said, hey, there's an embedded executable in here. That's not good. In addition to that, let's send the executable back to the dispatcher for further analysis, which then goes over to Clamav in the middle and says, I have detected that there is a Trojan in this executable. So in a moment we will see the alert technical difficulties in a video. There it is. Okay, so now we're going to reload the alert thing. And you can see that we have the two alerts. The top is the PDF that was found. And then the bottom shows the Clamav alert. Here's the original Clamav alert. It says this is bad stuff. But now we're going to go back and show you the PDF that has the embedded executable in the interest of providing as much information as you possibly can to make sure that you have everything you need to do in analysis. We've actually broken down the PE file using a PE analyzed function to then dump all the data and provide the analyst, you know, the ability to then do further reverse engineering if necessary. Okay. And that is it. Get back over to here. Current slide. Okay. I'm going to send it back to Ryan so we can tell you about the different types of nuggets and capabilities that are currently in the system. Patrick, you're way too tall. All right, there we go. Okay, so part of the reason that we're here talking to you today is that we want to kind of solicit your participation in the development of new nuggets given that it is an open source project. The following slides kind of represent what we've been able to achieve in-house with a minimum amount of time and effort. But anyway, you'll notice that we tried not just to include... We tried not just to include stuff of our own, but we tried to integrate a lot of third-party software as well so you can see how the framework allows for that extensibility that we talked about earlier. Okay, so we watched the demo. We looked at Snort as a collector in the context of SMTP traffic, but we've also got web and DNS builds. The reason that we... Snort is good for this sort of thing is that, one, it's an easy way to get stuff off the wire, and two, it's really easy to incorporate. Also, if you're interested in file fuzzing and more of an attack research-oriented kind of person, we've got a custom post-mortem debugger. What that'll do is it actually track applications as they crash and send the variant of the file through the dispatcher, which caused the crash, along with any context information. By context information here, I mean the actual instruction, which it crashed on, and the exploitability of that crash. So this has a number of really useful applications. What it was originally intended for was, as a sort of monitoring system for your client machine so that if somebody opens a file that goes through the system and detected, but accidentally causes or actually causes a crash, then all the information and context information surrounding that crash would get sent through the dispatcher and alert would be generated. However, if you're interested in file fuzzing and have a fuzzing farm as we do, another cool application is to have a set of machines that are charged with doing a breath-first search approach to file fuzzing, and then once they've found a crash, they can actually send that crash to another set of machines which are responsible for doing a depth-first search approach to fuzzing, allowing for a very, very efficient fuzzing system. You can also fuzz your own kind of in-house software with this as well. All right, so here's an example of a third-party piece of software that we've integrated. Dynamics PDF Dissector, which is actually, hold on a second. So this is a great third-party piece of software that we've actually been using to break down our PDFs. Essentially, it's able to report known vulnerabilities, understand and decode obfuscated and potentially malicious JavaScript, and also extract exploit shellcode for further analysis. It also provides normalization such as JBig2Decode and the ability to hook known exploits. It's extensible, which is the part that we like about it the most because we were able to use kind of their library to create an interface with the framework. And in particular, the ability to hook JavaScript calls allowed for some interesting results. Hooking the Unescape call allowed us to flag potential shellcode and some simple pattern-matching on large allocated heap blocks can allow us to look for potential heap spray attempts. So any shellcode that you do find can be re-interged into the system and sent to a shellcode analyzer. And for this, we used libmu. For those who are not familiar with it, it is a library that offers x86 emulation and shellcode detection and execution capabilities. So some noteworthy things that it can do is win32api function call hooking. You can also look for blocks that unwrap shellcode and profile shellcode behavior. The profiling of shellcode behavior is especially of interest to us because that allows us to generate alerts that can describe the intent of shellcode, the goal that the shellcode was trying to achieve, what those instructions were intended to do, which is nice. All right. We've also got an OfficeCatNugget and a FlashNugget. So for those who are not in the know, OfficeCat is an in-house, ongoing VRT command line utility that allows you to parse Office files and look for known vulnerabilities in them. It was probably our earliest attempt at addressing the whole client-side attack issue. But anyway, we've integrated that. Actually, our malware engineer, Alan Z. Duwemba, did a really great job on that. We've also got a FlashNugget which can decompress and analyze Flash and detect some known threats, which is pretty cool. Clamav is an open source antivirus that can analyze any format. It offers SIG-based, pattern-based detection in the form of NDB and LDB files. But you can actually also write your own C code for it. It's got a bytecode interpreter, which I think is fairly recent. One of the cool things about this is that it's got an updateable signature DB. So you can update it in one of two ways. Either you can update it yourself or you can run a utility called FreshClam, which will grab fresh signatures from an online... from an online database. The cool thing about this is that it can further serve as a collector and issue defense updates. So if you found, by some other means, a file sent through the system to be bad, a signature can be generated on the fly for that and then added to the DB so that Clam will alert on any future... any future encounters with that file. Our own Alan Z. Duwemba was also responsible for that. We also provide a deep alerting system. It offers detailed context-oriented data. So we talked about stuff like timestamp, whole portions of the file, normalized pieces of the file, cleaned up JavaScript, you know, source IPs, et cetera, et cetera. A lot of information is provided by the system. The Maltigo interface, this is actually kind of still in progress, but if you're not familiar with it, it's a self-described as open source intelligence and forensics application. It actually data mines and aggregates information and represents relationships between data in a visual way. So we're still in the progress of toying with that, but the cool thing about it is that we talked about those correlation nuggets earlier and this would be sort of the prime example of something that could potentially become a correlation nugget. And finally, workstation nuggets. Workstation nuggets are basically just a slick human interface to the system as a whole. So you can view existing alerts in the database. You can check the status of nuggets across the system. You can also run a standardized report set. So if you've got like an 8 a.m. meeting and you have to report on a variety of things, you can essentially just sit down at your workstation nugget and look at only the data that you need, print out the report set and you're done. And with that, we're going to talk a little about the API, which is the interface for programmers with the system. Ryan, you're too short. Okay, so we're going to talk a little bit about the API. Don't worry, I'm not going to put a bunch of code up here. However, I'm going to have some slides. At least it has a function name. Sorry. What we've tried to do is make sure that we take care of all the basic tasks that need to be done. You know, we want you to be able to just do the things that are important. You know, think about what kind of data you're, you know, that goes into this and that goes out. What data am I looking at? What data do I want to generate? So we take care of everything including, you know, opening up a network socket if you're going to receive data from the dispatcher. We take care of threading. We take care of all the interactions with the database. Like I said, we want to make sure that all you have to do is deal with the data that you're getting and the data that you're trying to create or present. So, again, since nuggets are, you know, building blocks and the whole system is designed around the idea of building blocks where you take, you know, individual pieces that are specialized and have them work together as a whole, we have some general functions. Register Nugget tells the database, hey, I'm here and this is, you know, this is my name, this is my UUID and this is the kind of data that I'm either, you know, either taking in or putting out. Register Handler is kind of more of a detection nugget function. It tells the dispatcher what kind of data that it handles and it is possible to have a single detection nugget handle multiple types of data. You just call Register Handler with a bunch of different function pointers to tell it what kind, what functions to call if it gets the relevant type of data. Okay, so collection of detection nuggets. As I mentioned before in the demo, you know, we have the SMTP parser nugget, which is a detection nugget but one of the key things it does is actually get data in, split it out into little pieces and send it back as all detection nuggets can do. So since that has this, you know, that's kind of the same idea of what a collection nugget would do, they both share send data and send metadata for providing data back to the system and the dispatcher. Detection nuggets of course also have send alert, which as you would expect, sends an alert that is then handled by the dispatcher and sent to the output nuggets. Intelligence nuggets, they're more of a, I think I said before, it's not necessarily event data or alert data. It's just kind of data that we're adding that we want to be able to keep track of later in case we're trying to track something more intense. So as such, they are really interfaces for adding information to the database. The types of protocols that we have right now are email, web, and DNS. But, you know, more protocols are on the way and if you have any other types of data that you want to put in there, it's really as simple as creating the schema for storing that data, creating a function for populating the schema and you're on your way. Okay, what if you don't like C? Well, shame on you. But if you want to use some sort of scripting language or something else other than C, we do cater to that. We actually, I apologize, we don't actually have these APIs available right now, but they're close. But Ruby, Python, and Perl, if you have any other languages that you wanted to write nuggets in, past school I guess, small talk, just create an API, just have the C wrapper if it's available, it can be done. Okay, so conclusion, the Razorback system, you know, I keep saying it's very modular, it's very scalable. You can sit there and you can have individual machines that have single tasks that they do. Or if you want to do a more smaller scale thing, you can have one machine that runs a bunch of things. We really make it so that you're able to set it up however you want to do it. It's really limitless possibilities and that's the goal. We provide a framework, you provide what kind of information you want to handle and how you want to handle it. So I'm glad you guys are all excited. I know you guys want to go home and start writing some nuggets now. So the different kinds of things that we need, and again, this is open source, everything's GPL, V2, it's the end map license. Collection nuggets, we need additional protocols. There's all sorts of protocols out there. We've only done a handful of them. More are coming and the more community involvement that we get, the faster we can really get this thing going and get it useful to not only you, but to everyone else. Detection nuggets, there are tons and tons and tons of file types out there. We've only scratched the surface. As Ryan said, they're all crazy people so the more people we can get to try to parse their craziness, the better. Defense update nuggets, if you have some device that needs to be updated, we don't have every device out there. I mean, nobody does. So if you have a device that you use and it's something that you want to get that feedback, and especially correlation nuggets, that is something that we definitely need help with. If you are an expert at data mining and knowing how to take all these pieces of data and making something useful out of it, please, please get in contact with us. We have a lot of stuff to do to correlation nuggets. It's not necessarily our strong point. As you can see, everything is all available on Source Forge. Razorback TM, notice the TM, Razorback was already taken. That is the main project. And then there's Nugget Farm, which is the repository for all the nuggets for handling all the different pieces of data. And if you want to, you can also go to the Source Forge tracking system to see all the things we screwed up and hopefully have fixed. So we'll get to questions. There's various context means. I'm Patrick Mullen. That's Ryan Penney. I want to point out the Razorback team. The entire team has been working so hard on this. They've really put in a lot of effort. I'm really proud of the team. Anything to add, Ryan? Oh, oh, yes. Important distinction. Remember, we are in version 0.1 and not 1.0. Everything is a work in progress. Things do work. Speed is not necessarily the primary goal while we're writing this code. Things usually work. Sometimes it works for me. But we're really at the ground work. So, you know, the ground floor. People want to help out on any part. Really appreciated. Any questions? We have five minutes while we're here. We can tell more jokes or people have questions? Quick announcement. Just a real quick announcement. The track after this has been canceled. It's been replaced with Spot the Fed. So if you're staying for the next track, it's canceled unless you want to stay for Spot the Fed. You've got an extra 10 minutes. Okay. So any questions? Yes, sir. Oh, that's... Okay, so the question is what kind of security concerns as far as the architecture of the Razorback system have been made? We... It's not there yet. Again, it's version 0.1. But we have put thought into how we're going to do authentic registration, authentication devices. So we can take care of that part. One thing to remember is that since this is written in C, you know, if you write bad code and we send you data that's from the wire, you know, they are vulnerable to whatever it C is. So we will take care of the secure authentication and authorization of all the components and whoever programs the nugget is responsible for making sure that they handle inputs correctly.