 So let's finally talk about visual security event analysis. Okay, I need to take this out of here. So what I'm going to talk about is how you analyze log files or events that you have in a visual manner. I don't want to talk about myself too much. Maybe one thing, I've been involved in like log analysis and event analysis for quite a while and it's always interested me whether there's a way to look at the data in a way that it's really like a lot of data in a way that it's really apparent what is going on in that data set. And if you're looking at log files, thousands of lines of logs, it's really hard to figure out at one glance what is going on. You have to start reading through them, you have to like use your own mind to do pattern analysis and figure out what is really going on. So at some point I started working for this company that I'm working for right now called ArcSight and I got a hand on a lot of neat tools to look at data and we got a feature in the software that is called EventGraphs and I really liked it and I started looking into how can we use this feature to make it more easy for a security analyst or a person interested in the log file to figure out what is really going on in that data set. So that's how kind of my passion about EventGraphs started. My talk here is not going to be very textual or like theoretical and I'm not going to talk too much about how you generate the graphs and whatever. I want to show you a lot of examples on how to look at data sets and how you can figure graphs to get the most out of it. As part of the talk I'm going to show you a tool that I have up on SourceForge which is called Afterglow which is a very simple Perl script that transforms CSV files into a graph or language file so you can go home and play with these things yourself and a tool is actually also in the CD. I'm going a little faster in the beginning so we can catch up with the time I lost already. One thing IP addresses and host names you're going to see in all these graphs and the descriptions are obfuscated or changed. The addresses are completely random and any resemblance with well-known addresses or host names are purely coincidental. Alright, so let's do a little bit of an introduction here. Why would you want to look at these graphs? I guess this is a pretty good example already. Do you want to look at the left-hand side or do you want to look at the right-hand side? Well, even if I made the font bigger on the left-hand side it's probably still not very fun. Alright, why do you want to use EventGraphs? I guess I already motivated that quite well. I'd rather look at the graphs. They look just much nicer. If you actually dig into it a little more and you start looking how to configure these things you will see pretty quickly that you can visualize different properties in those graphs and it's very easy to see certain aspects of a log file very quickly and certain things that are important to you. You don't have to wade through 10,000 of lines of logs to figure out whether there is anyone sending a lot of emails to someone else. If you use this in a security operating center or in a 724 response team or something if you have graphs there are great ways of giving you situational awareness or real-time view on things that are happening and you can quickly react on them. We have a lot of customers that are starting to use this in their socks and it doesn't just look pretty on their big screens but it's actually really useful. It's actually also kind of an interesting story. I was with one customer and they had all these big displays and they were empty and I was like, wow, why do you have these nice graphs here on the analyst screens? Why don't you have them up there on the big screens? They were like, whoa, no, no, no, we tried that for a while but then the boss came in and he saw all these things on the screen and he was like, oh, what is this? What's that? What's this? What's that? So we had to explain all this, we took them off. All right, and one other thing, another story that I had with these graphs which actually two other stories, one is one customer uses these graphs to communicate with other teams so you have the security analysts, they look at the log files and all that and then they go back to the operators or the operational folks and they're like, guys, you have to do something about this machine it's talking to all the others in the network and in the past they were handing them log files to prove that it's that way and the operators were like, whatever, we don't understand what this is but now they started giving them graphs and the operators were like, oh my god, my machine is talking to all these, we're going to take care of this. And even worse, I had one customer that actually just told me this week that he used the graphs to analyze some data and he found some stuff and one of the guys got fired just because he used the graphs and found out that one of the guys was not doing his work. All right, so I came up with like two big categories of when to use these event graphs. One is in a real-time monitoring scenario where you have like a screen app that looks real-time and certain properties of your data file and I'm going to show you some examples of what I mean by that. It gives you great awareness of things that are happening. You can configure these things to, for example, look at transactions going to your financial servers. So right away if someone connects to your financial servers you will know and then you can take to the level further you can say, well, I know that these machines are okay to connect to my financial servers so don't show me those but show me everything else. So as soon as something pops up there you know you got to look into it. The other thing is if you take this in a more forensic or historical way you can, you grab a data set, you run it through some tools and you look at the graphs on certain properties and you figure out what's going on. Let me mention quickly some related work. There's some classics from Girardin Luc. He did all these kind of things. He tried to figure out whether there are certain ways to visualize properties of data and he took a lot of dimensions and put them all in one graph. What I'm going to do is I take a lot of dimensions too and I'm always going to stay with event graphs so like node-to-node connections. I'm not going to use any of the parallel coordinates or the right hand, the bottom thing that I have no idea what it shows there. Then Errbacher, he actually went even further. He tried to go even more multi-dimensional and map everything into these nodes. So there's like size, there's shape, there's length of these spirals going out and so on. Then Greg Conti, you probably have seen his talk, I hope. He mainly focuses on different ways to visualize TCP dump or packet locks. Very interesting. Then Envision IP is something I found. What you see up there is a grid of, I think it's 8x8 or 64x64 and they just map IP addresses in there so you see certain classes of things going on. The nice thing about this project is there's a lot of interactivity so you can start playing with the data, you can zoom in and so on. Finally, a few of you might know Shoky from Steve Berry. It's basically a scatter plot. You can define three different scatter plots and then you have a 3D of that. On the top right, it's not a very nice picture but on the top right it's a three-dimensional output. One axis is your source IP, one axis is destination IP and the other one is the destination port. All right, let's move on. How do you generate an event graph? Pretty easy. You have a log file that a device is generating. You take a parser. Why do you take a parser? Well, you need to know where in my log event or my log file, where is the source IP, where is the destination IP, where is the event name, where is the port, so you parse that, you get the syntax right and then you visualize that in an event analyzer. If you have an event, let's look at the snort event here. You don't have to be really able to read this but what I want to show here is in an event graph you can have different configurations. The normal event graph that you will always see is like who is talking to whom, so you have source IP, destination IP but you can take this a lot further. You can say, well, on the right top you want to have the source IP, destination IP and destination port so you will see someone port scanning, for example, if there is a fan with destination ports. So you can configure these things in pretty wild ways and I'm going to show you some of them. Now, let's have a sneak preview of Afterglow. I apologize because I don't use my laptop. I can't show you the demo. It's not very fun anyways. I will show you the output anyway so it doesn't really matter. So what is Afterglow? Afterglow is not a security information management tool. It's just a script which takes CSV files so you have to somehow from your logs generate a CSV file, comma-separated values and then you take Afterglow, the tool that I'm going to show you and you transform the CSV files into a graph language file and then you take a grapher tool and right now I'm supporting two of them and it takes this graph language and generates the graph and that's not something I did. I just transformed the CSVs into graph files but I'm going to show you some cool things that we implemented there. So how you can use this thing is you basically cap the input file, you pipe it to Afterglow, you give it a color properties file which I'm going to introduce a little later and then you can use the AT&T Graphverse library.NEDO I'll give you references in a second and you generate a GIF file. Now color properties file is basically just you tell it the source nodes are red for example the event nodes are green and the target nodes are blue and I'm going to show you how to really play this with this stuff, we extended this quite a bit so you can have colors depending on the values in the log files. Big shout out to Christian thanks a lot for building the foundation of this tool. He built me the whole Afterglow profile, the basics and everything and I just went in and made some small changes but thanks a lot Chris. Let's look at examples. I mentioned in the beginning I kind of have two use cases or two big categories of things to look at one is what I call situational awareness or real time monitoring. So this is one of the views that I saw at a customer basically you see here is six independent screens of different properties of your data that you want to look at. So here the configuration is such that on the top left the customer wanted to see just the compromise attempts and don't ask me how to filter for just those events that's a whole different story but if you have a way to say these are my mildware events these are my DOS events these are my scan events if you can separate them by something you can look at these screens and see what's going on so what this customer is actually also doing whenever an analyst starts a shift he resets all the graphs so they're empty so over time nodes start popping up and they look at them and they're like okay this is fine and they might filter them out or they just leave them there and say I know about this and the more things that show up the more they go along in their workflow and work with these events it would be a great tool especially in a SOC or an analysis environment to kick off your workflow you look at these things and you take it on and you start building filters to filter out the things you know about and you just see the outliers here in these screens the second big group of use cases is forensic analysis or historical analysis where you take a log file that you have and you visualize it afterglow can generate two kinds of outputs one is for the AT&T graphless library for .needle and the other one is for LGL the large graph library I will give a pointer to that in the end as well this thing is generating three-dimensional graphs you can actually generate VRML output and you can fly through these things I didn't prepare a demo because it's kind of fun to fly through it but the analysis value is not really high the value you get out of it it's really cool to fly through it this guy sent an email to whom oh there it looks great and I apologize for the callers here but this is really how it looks anyway let's go back to 2D this is a very simple example one of about 12 that I'm going to show of how to analyze a log file so what I had here is I believe a blog or a web blog or something and I said well show me what is happening so the event name the destination IP are the blue ones and then the destination ports are the white nodes so what you see here all the blue circles are my web servers the white boxes are the target ports that they're being connected to so you see it's 80 and 443 so that's totally legitimate only HTTP and HTTPS traffic is going to my servers so I probably don't have to worry about that if I would see a node there like port 21 and someone connects to my web servers with FTP maybe that's okay but if I'm not running FTP in my environment and that shows up here I probably want to investigate that so it's a very quick way to see whether traffic is really what it's supposed to be same configuration here you see source IP destination IP destination port so this would potentially show you port scans or network scans here you see a lot of machines connecting to a lot of other ones all on the same port down here this white node here so they all connect to the same port well it could be that a warm is probing you but it could also be that you have a web server and a lot of web servers and a lot of machines are connecting to those so it might be okay but it might be a scan what the destination port is you might figure out what's going on in this case but you can certainly tell well this is all similar behavior here on this fan and then actually if you see on the bottom left here there are some little ones it's probably worth investigating what those are and probably those are the outliers that you are interested in let's keep this configuration of the graph this is just a little bit of different data set in a different time looks much prettier let's zoom in on the bottom part here what this is showing you that there are two machines the red nodes they're connecting to about 15 other ones and still on the same port so again in your environment do you really have all these other 15 or 20 machines serving this one service and exactly two machines are connecting to them so you can go and figure out what all these machines are and hopefully they are really the ones that are serving this service and then you can figure out whether these other two are really allowed to connect to this let's have a look at this weird thing over here what you see here is probably you can't read this but there's a node here that says 21 fdp so one of the properties of this graph is that the white nodes show up exactly ones per target port 21 is going to show up around that thing there so again I can say wow I have about 6 fdp servers and about 5 people are connecting to them so the fdp servers would be the blue nodes and the red ones would be the people using it so this is really something I have in my environment and why are only 3 or 5 people connecting to them is that some kind of a process I don't know maybe AIX that transfers log files over something weird like that or is this something malicious is anyone having a ware server or whatever if you interpret these graphs you have to be a little careful I still have the same configuration destination IPs are the blue ones and the white ones are the destination ports well if you look at this on the left hand side I would say wow it's a port scan well is it really a port scan the one that gets this right what is the left hand side no not voice over IP was that that over there you got the book it's the source ports the log file reports such that the source port is really the destination port and the other way around so when you analyze these things be careful and make sure you're really looking at what you're looking at so why do I know this are the source ports and the destination ports well during the 50,000 range they're almost contiguous and I mean who is scanning me on these high ports we're not a capture the flag there they might scan you on those high ports because services are running all over but here there's really no sense why someone would scan you up there there's probably nothing there listening anyway so be careful when you analyze these things sometimes it's port scan sometimes it's not false positive let's really figure out whether that's true okay let's get fancy here this is a firewall log basically I show you passes and blocks from a PF firewall if I would just visualize source IPs destination IPs I would see big clouds of things and well I want to see a little more in this graph so what I did is I have source port rule number that's the squares and then destination IP so you will see I'm connecting to some other machine and rule number 100 is responsible for letting me in or blocking me what I did then with Afterglow is to configure my nodes such that all the external IPs are going to show up as orange I'm going to show you how to configure Afterglow to get exactly this graph so the external machines are orange my internal machines are green and you see I only have a few of them and then the rules are the blue boxes and then further what I said I wanted to see whether a connection is incoming or outgoing of my network so I configured the edges such that outgoing connections are blue that's the majority here and incoming is red and I just realized it's probably exactly the other way around I hope there is more incoming than outgoing because this is our web servers that are servicing some stuff anyway so so you see big clouds of things that are showing similar behaviors so down here there is this one rule that is responsible for letting in a whole lot of traffic and probably that's fine there's another one up here you can if you know the rule set if you know your ACLs you can go and figure out whether that's really what it's supposed to do but you can also figure out some things that are kind of weird you have this whole section in the middle you probably want to zoom in on those and filter out all the others and just look at these things and figure out whether your rule set is really doing what it's supposed to do so the next steps would be so the first is like overview general impression what is going on is there anything really sticking out and then my next steps would be I would visualize the firewall blocks of outgoing traffic why would internal machines connect with the integration of the internal box or the firewall rule set is wrong then the second one would be I would probably look at blocks of incoming traffic I want to know who's poking around and if you have a live system that can look at these things you can put all these attacker machines maybe on a blacklist and if you see them again and they're successful coming in you might actually take some action and say now someone probed me and now he's coming in and you can visualize the passes of outgoing traffic this is really what should be leaving the network maybe you find someone FTP and stuff out that you really don't want to FTP out maybe you realize that you're running peer-to-peer clients in your internal network and they're connecting out anything like that and you can probably take a few more steps to analyze the data set but I guess you get the idea so this one is probably the wackiest graph I have going away from source IPs and destination IPs what I did here is I wanted to debug my firewall rule set so it's still the same data set as before but this time what I show you is the red nodes are the rule number or the ACL number then the destination ports and then you see the action taken pass or block so just by virtue of firewall rule configurations you will see two distinct graphs one on the left hand side is all the passes and the right hand side is all the blocks so here you can see if you take one of these blue nodes for example port 53 here you see that this one rule is responsible for letting traffic in well is this okay maybe hopefully but you have other ones where there are two nodes or three nodes connecting to the same rule like over here for example there are three ports being being blocked by this one rule might be okay might not if you see something like this on the other side that one rule passes traffic for multiple ports maybe that's the way you configured it but this is certainly a great way of analyzing and debugging your firewall rule set this is another example where I took a TCP dump log and what I visualized here is I take the region of where the source IP resides so you can go on the web there are databases that show you what the location codes are for the IP addresses they're not very accurate but in a lot of cases they're actually pretty good so I show you the source region where it's coming from in the world then I show you the source MAC address so this is a TCP dump log the source MAC address is going to be the last hub probably my router that let the traffic into my network and then I show the destination IP so what I see here I have four boxes the four white ones that are my internal machines and interesting enough I have two entry points into my network I have two source MAC addresses showing up and then I have these two fans in the middle part what this is showing me is I probably either have a redundant router set up maybe I have a load balancer and what is interesting here is that machines up here they're connecting through this guy all these guys here are coming through both of them and all these down here come from the other one so maybe this is a regional load balancer that everything on one side of the world takes this entry point everything on the other side is using that entry point so if that's really the case a great way to analyze this log is this graph here and you can actually figure out why these two in the middle are coming through in for both of them and this is just a zoom where you see the one server and here it's like you can't even read it below the node here but it's a sand hill over there in the United States all right graphs like these are a lot of times indications for warms but again be careful there's a nice fan here of source IPs using the same event going into a few destination IPs well it could be again it could be a worm that is using to try to get into a network but it might again be a web server serving just legitimate files what you have to do in this case you have to figure out what is this event name here that connects all these dots and this might give you an indication of a worm or not if you're visualizing a snort log file and this talks about worm well it's probably a worm but if you visualize a TCP dump log file like an ICMP port unreachable it might not be an indicator for a worm trying to probe UDP ports and you get ICMP port unreachables back so you have to investigate a little bit to figure out whether that's really a worm I was playing Capture the Flag actually this year and last year and I was trying to figure out the challenge really for the analysis team on Capture the Flag is that all the traffic hitting your web server or your servers seems to be coming from the same IP address there is malicious traffic of the other teams hacking you but there's also benign traffic from the scorebots trying to figure out whether your services are still up so blocking all the traffic is not working so you have to figure out a certain way of distinguishing these two types of traffic and you can't do it by the source IP which you would normally do in your corporate environment so I started visualizing this log file of TCP dump and I just wanted to have a general feeling for what's going on so what you see here the dark blue ovals are destination ports that are below 1024 normally services that are offered to the outside world then destination ports higher than 1024 a light blue and then you see here what I just explained the red node this is what all the traffic that's coming in is coming from this one IP I configured it such that our machines, the internal targets are green other teams' targets are brown and then internal sources are yellow and internal targets are the boxes so what you see here we have two servers well there's a third one showing up down here this was actually not a server but I think that was that was one of the machines on our network that someone connected to that could have been one of our team members connected to someone else's machine and then the services that we offered were these six and it was all kinds of weird things I don't even remember what it was last year part 9999 or something and there was some mud running there but this gives you a very quick way of looking at what is happening in this network well I took it a little further I had an idea or a few people had an idea and said well maybe it's a TTL of the traffic coming in maybe you can distinguish the good traffic and the bad traffic by looking at the TTL so well what I did is I said show me the source IP to destination IP and then the TTLs of that traffic so you see here I have 8 TTLs showing up 8 distinct TTLs everything from 35, 50, 50, 2 64, 128 and 146 some of them are showing up if my teammates would connect out so I could filter them out I was not interested in those I'm just interested in the ones that happen of the traffic coming in from this one evil IP let's go back quickly again and then I figured out well I still can't quite tell what is okay and what not so I had to reconfigure my graph and look at some other properties so what I did is I said well I'm not really interested in the IPs I know everything is coming from this one IP that I'm interested in so it only show me the traffic from that guy but I'm interested in the destination ports the TCP flags and the TTLs so I wanted to see like the SINs, the SYNACs the pushes and whatever and their TTLs and what port they went to so this yields this graph here and in addition to that that was not quite enough to figure out what's really going on I need to have the counts I'm gonna lose everyone here I need the counts on all these nodes so how many times did certain flags show up so let's take one example here I have port 80 here it showed up 2600 and something times and these are all the flags that showed up with the different TTLs so there were 4 TTLs 1, 2, 3, 4 that were used when someone connected these ports here and here are the TCP flags that were being used for this traffic so I had a theory I said well I'm looking at all the connection establishments all the SYNs and I want to see how many times they happen the score about traffic is probably going to all the services in sequence are probably the same amount of time so I will see the same amount of SYNs going to each of the destination ports and if the theory about the TTL is right they all use the same TTL and it turned out that we were actually able to figure out the TTL for the game last year that way and we filtered all the traffic but it was a little late in the game alright so I have some other logs here at some point I was interested in email logs and I wrote a little send mail parser and that's actually part of the afterglow scripts that I have that you can have on the CD or you can get from SourceForge the problem in send mail I will mention that in the end I guess there are always 2 entries it says from so and so and then there is a message ID to link those 2 events together or just 2 log entries so I had to write a tool to actually put them together and then output a CSV file and all that stuff and the result is this one here so I am just showing who is talking to whom by email and then I said well what is probably interesting is to see everything that is coming from my domain the one that I am really hosting on that server going to people outside and what is coming into my domain so I colored the whole graph that way and if you look at the zoom up here you see that these people here are quite popular a lot of people from outside these red nodes are sending emails to this guy that was hosting on this server here you just see the popular people you might be interested I don't know maybe I want to get to know them but I was really interested in whether I am running an open relay I am not but I am pretending I will so what I did is I said well just show me everything on the outside all my domains or all the raffi.ch or whatever my domain is the great amount and just show me the rest so you see there are still some others showing up here so what I did then I used afterglow to just eliminate all those I show you how to do that you can set notes and invisible and here I realized oh my god there are actually people using my server like this guy here to send emails to people that are not hosting on my server so I am probably running an open relay well some other things I was interested in well am I running spamming well hopefully I see something in here otherwise my graph would probably not be very my configuration would not be very good because probably on every mail server you will find spam so what I did is in the email log you see the size of the messages so I just visualized who is getting what sizes of messages and I was interested in just the ones that are above 10,000 all the others I am not interested in so you still see that for example down here there are multiple recipients that get the same size messages so that means that someone probably is sending emails to a few people and this email is pretty big and it is probably the same one because they have quite a high size the same size so that would be one indication of maybe there is something spam going on probably not well another way of looking at spam is the number of recipients in an email you can send emails to multiple people right so the number of recipients in the log probably indicated how many people got this email and what I said well I want to see everything that is bigger than two and all the things where someone is just sending to two other people I don't want to see so I have this omit threshold thing in afterglow I will explain that in a second where I can drop out nodes that only connect so I can filter out the things they are not very interesting I am interested in the bigger the fans or the circles showing up so when I did that I realized well only this one comes back here there are like 10 recipients and 7 and 11 and it is always from this free club report at news.ca so it was probably a newsletter and maybe it was spam you can take this further and further you can have very big you look at very big emails maybe someone is sending out documents from the internal network to someone outside I am going to skip over this a little quicker to show you afterglow what is interesting another one is there is a field called delay on the email and that shows you how long was the email queued on the mail gateway and what you see here there was apparently some problem here if you speak to clouds this one here and this one down here these emails stayed on the server for more than 10 minutes and it happened a lot of times as you can see to these two email addresses this one here and this one down here so there is some problem with those addresses maybe they are wrong and you can go in and either block them or do something about them and send the emails out to these guys and this might actually be also a way to detect spammers because they send these huge lists of emails and probably a lot of them don't exist and they will be queued and system they might retry all the time so getting a lot of delay so maybe you can figure out who your spammers are okay let's get to the gist here to afterglow you find it on sourceforge as I mentioned earlier already I support two output formats the graphers library from AT&T also known as .NITTO and the LGL the large graph layout by alex adai if you afterglow is just a pearl script you can pass it the input you can read some standard in you can pass it a few parameters you can figure it one of them is if you do a minus t on it it expects a two column input so just from two size and recipient or something like that so minus t reads two columns if you don't do the minus t it expects three columns so you can do all these source IP destination IP destination port things if you do a minus t it will print the count on the nodes that was a weird example from capture the flag I showed you that you actually see how many times did that node show up in the log file then you can pass it an edge length you can recognize how your graph is going to look if you have a length of five then things would be really distant from each other but if you have big clouds around one of the nodes that might be helpful with minus n you can disable the node labels so sometimes you have logs if you can't parse them really well you have really long tokens so they will really clutter your graphs so just turn them off and you get kind of a feeling that there are certain things going on that might be helpful this minus o thing this threshold that you can set if you have a log file of communications like someone is talking to someone else and you see a lot of people that just connect to one other machine and nothing else and then another machine to something totally different but then you have these big clouds a lot of times I'm not interested in these one-to-one connections I'm not interested in the big clouds so if you do a minus o one it would kill everything that has a fan out of one and this feature is not quite complete it doesn't do the whole traversing of the clusters and figure out whether it's connected to other clusters play with it, it's kind of cool there might be one off cases that look kind of weird and then the most important thing is the minus c you can parse it a color property file I'm going to show this in a second how this works so the property file just has color dot for example source equals and then it can pass it a pearl expression and the expression just has to return a color like red, this string then there is an array called fields that contains the the columns that you passed it in so for every line it will evaluate this array so you can say that the event node is red if the first column so that's really the second column if fields one matches this regular expression so it's in 192 then make it red then I have the special color called invisible if you say that the target is invisible if this expression here matches then it won't draw that node so you can kick out certain things by certain expressions oh you just have a simple color you just say color dot edge equals blue so here is the fancy example of the file well graph I'm just very quick so this is the property file you say the source is olive drab if the field zero so if the first entry that you get is 1,191,141,1694 that's one of my IP addresses it's not really so go and play with it so they show up green and then everything else like first match wins so if it falls through it will just be orange red so everything outside is going to be red then you configure the nodes there will be blue, the targets like I think you get the idea here you can have really complicated things on the edges for example for in going and outgoing traffic I had to say if the first column is in Simon at work or the third column which is the destination IP is inside my network then give it a fire break color and otherwise just use the other color Afterglow also has two parses I give you and I just realized I just put this slide in last night at like 230 I hope there are no typos I realized that these two parses are actually quite useful I used them at Capture the Flag yesterday if you have a TCP dump log file and you want to visualize that you have one problem you see requests from a high port to port 80 then you see the response going from port 80 to a high port if you visualize that you will see the high port and port 80 as source ports and that was what I was showing in the other graph basically and then the destination port again same port numbers so for the request you need to flip the TCP dump the CSV takes care of that it remembers what direction the connections are going and automatically flips them so you get nice output and then the send mail parser combines the send mail log entries into one again that you need that's really it any questions? wow everyone is tired so the question is whether I'm thinking about using like a database to drive or to read from well after it was really just like a unix script right you use pipes and you pipe in data and you get data out so it's pretty easy to use a SQL database for example you use the TCP dump to CSV you pipe that into MySQL insert into blah blah and you get into database and then you can have it piped into something else and you read out the stuff from the database and you run it we basically just provided this afterglow to take the CSV to add the color and then everything to that graph file and generate the graph file and then you use the grapher to generate the graph but please feel free to contribute anything to the source force project and also if you're going ahead go home and visualize and get some cool graphs I'm always interested in getting graphs as it well most of the time it's actually consumed by NIDO that's what I use to generate all these graphs here because it has to generate the layout and it really depends on how many nodes or how many log entries you're passing in it's if you have probably about let's say we want to have a refresh rate of like 30 seconds I think that's good because you need time to look at it and then it's going to change completely again so one of the problems you don't see nice delta updates you would have to handle that somehow it might be something maybe Greg and I could work on so if you have 30 seconds it's probably safe to use up to probably 5,000 events in 30 seconds that should probably work I think I did something like that yesterday with the capture to flag data I have two more books I guess I give them to the two gentlemen that asked the questions here anyone else? alright thank you very much