>>>:  Good morning party track how are we doing? How many people here came to learn about home alarm systems?  Alright.  You’re not going to learn about home alarm systems.  The spearker had a small problem with his employer to that talk is not going to happen I can guess and I'll summarize is even though I have not read the talk. Your home alarm system is kind of fucked.                                                >>>:  Oh, alright!  Yeah. 
>>>:  So with that out of the way let’s fit in a bonus talk ok?  This is my good friend Zack, we go back a long way.  He's going to give you the most entertaining talk about logs that you're all day.  So let's give him a big Party Track welcome! (Clapping) 
>>>:  This is the most exciting one because there's no other one. 
>>>:  Okay, before we get started this is Logan.  And we'll say hi to Logan.  He was supposed to speak in this slot about home alarm systems.  But last week this article came out and it sounds that we had to cancel.  More recently NPR got an article with him, I pinged him a few times, we wanted to see if he wanted to share some information, but he didn’t respond.  So I wanted to post this NPR article quick because this summarizes pretty much what happened.  He was supposed to be on stage but because of the pressure put on him he can't.  So I'm going to leave those names up there for a second ... and we're moving on ... so in honor of Logan because he couldn’t make it I decided to start this with a ridiculously good‑looking researcher so he can impress us with his smile.  And this is your top gear top tip so if you're going to do this the top tip number one is follow responsible disclosure if you're feeling nice.  And tip number two don't name the vendor in a press release unless your goal is to get your talk pulled and if you're going to give the talk and you're worried about legal action and go ahead and up the skate and make sure that you sell the job and if you're going to do what Logan did for the future maybe you're considering his talk or doing his talk, but instead you get me, logging by Zack. 
Yeah! 
>>>:  This is Party Track, isn't it? 
Okay, good.  Okay, so I would like to talk start off with what this talk is and what this talk is not.  So you don't have to spend the next 45 minutes listening to me ramble.  This is going to be a defense focused talk.  Okay, so if you're looking for some sexy Ode you’re not going to find it here.  We’re going to be talking about collecting, storing, monitoring, parsing – having fun with logs.  And make it fun and the reason is because it’s a reoccurring problem we keep having it over and over and over.  We're not getting good logging systems put together, we’re not getting good logging data in most situations.  Sure you may be the 1% here who is like “Yea I’ve got this shit covered.” This talk is not for you.  And if you know what “ELK” stands for and you’re an “ELK” rock star then you may want to go get a few minutes elsewhere.  Okay, this is going to be about a 200, 300 level talk on logging and big logging environments.  This is not about hacking your alarm systems and the wireless problems with it.  This is not an offensive security talk. And I’m not going to be addressing the challenges of dealing with over 200 gigs of log data a day.   And ‑‑ and that's going to be a whole different barrel of monkeys to deal with.  So who am I? ‑‑ I'm Zack.  I'm a managing partner over in Chicago.  I do things and stuff and everybody has their big line of credentials.  This is mine.  Moving on.  Okay, so offensives talks can get up here and rant about their cool awesomeness for a full hour about how awesome things are ‑‑ but really we're not going to use a lot of that stuff.  Yea it’s cool to hear about the insecurities and this and thatand when we come back to our day job we have to deal with protecting stuff so the vast majority of us need more defensive talks.  So let's start with logging... and I'm going to say it with an Irish or Boston accent.  Okay, so we're still having a logging problem, we’re still relying on log data and log formats that are archaic ... and we've seen that the technical community has this figured out but not from a security perspective.  There focus is on, you know we want to know if there's errors, what their habits are.  But InfoSec hasn't really figured it out ... and I don't know if it's because we're lazy or haven’t taken the time to look at it, but I figured let’s dive into this a little more.  We're not going to talk about generating logs, because that’s easy.  A configuration file and we could call it a day. And I'm not going to fill 45 minutes explaining a config file, it will put you all to sleep, even if there was music here at Party Track.  We're going to talk about the collecting log and storing and processing and most importantly the actual monitoring and security events for logs.  Why do we need logs? Because, Oh, I'm just storing them.  It goes beyond security.  We need it just from a management perspective to convince our bosses that we're doing what we're supposed to be doing  and we're doing it right.  A lot of the time we have to deal with the compliance stuff ... okay, full disclosure I'm a QSA now ‑‑ and I can't say anything about it ... so.  So logs are very short.  Compliances is going to be a driving force for stuff a lot of times.  And we can use that from a security point of view of hey I’ve got to meet this ICO, PCI, HIPAA, whatever it may be.  Whatever you have to deal with—we can use that to say, hey I need a little money and time to do the cool security stuff that I want to do ... we need it from the security monitoring perspective duh, incident responses duh and from a technical operations side, Dev Ops has this figured out.  They’ve got this figured out from the operational side.  But they don't really share that information.  Or we don't have a dev ops thing ....  And let's be honest about our current state of logs.  Most stuff just kind of sits there or gets deleted  and we have our logs rotate stuff for 90 days because we have to for compliance reasons and it’s getting deleted or we have to send it to some product that's a pretty little box or pretty little BM or pretty little software and we're storing it and when we have somebody come in to troubleshoot it or having an auditor or assessor come in and showing it to them.  But let's be honest with ourselves and confess right now.  We're not really watching them as much as we should.  We don't actually watch them.  And I think that a lot of it comes from the usual approach of watching a log.  But so the traditional approach of using a syslog server and regexs and grep and sending alerts and if it hits a certain thing it doesn't really scale well.  We can take and setup for multiple systems ...  it really defeats the purpose and being able to search leverage those and again like I said we can love our vendor products.  We have a lot of vendors.  But a lot of them have great products out there.  But they're expensive as shit.  And the whole model to do it as a volume based licensing. If you want to log more it's going to cost you more.  But I’m hosing my own data, it's going to cost you more.  It makes sense from a business standpoint and it makes sense from an up scale standpoint but it can get very expensive quickly.  I was talking to a friend the other day.  They had a two million dollar IT budget for all of their operating expenses.  And they had a large vendor and they wanted 400 thousand dollars to do the logging for their environment.  That's almost 25 percent of their years budget just to do their logs.  And we can use our moneys more wisely and I'm not saying that vendors are a bad thing.  If you work for a vendors and a lot of you probably do, I’m not saying oh don’t go buy the big guys data.  It’s great a lot of times.  If you have the financial resources they are definitely great.  And the offer of not having to have the typical talent to manage them‑‑ you can hire the guy who just graduated from college and say, here have fun with this product.  And they'll figure it out.  But we can be a little smarter since we’re people who like to tinker with things, break things and do things right.  Okay, I've been on this journey to find open source solutions.  And to actually share the open source solutions and how to configure them.  So I looked for scalable logging solutions that open sourced so we can tinker with it and don’t have to pay a license to distribute.  It’s reliable, scalable and secure.  And reliable and scalable is really important when it comes to your log and meets the compliance requirements that you have to follow.  Here are our top 3 winners, we’ve got LogStash, Elastic Search, Kibana, which I’ll be talking about today, aka ELK.  Also as runner up we have FluentD which leverages Elastic Search, they’re a great solution, I don’t want to call it a product because they don’t really sell it.  And there's Graylog2 as well.  Okay, as you can tell Log Stash and Graylog are JAVA based, I know, boo, hiss, JAVA memory consumption but they work and then FluentD is based so groovy.  So we'll be focusing on Log Stash, kind of going through what is this Log Stash, Elastic Search, Kibana stuff and how do we get events and process them and search them and most importantly impress that boss.  Okay, that's the end of my talk and you should just go use it and we're done.  This is my water break.                                           >>>:  Okay, so the biggest pains for logging a lot of us face is we're getting a lot of log data data from a lot of different sources that come in all these different formats and all these different time stamp formats and sometimes they’re this and sometimes they’re that.  And we have to parse them, make sure we have the accurate time for them.  So Log Stash processor tries to do that.  So this is a look into how Log Stash processes its data.  So from a shipper perspective that’s kind of your agents that are actually entering those logs and sending them to a central source.  You have a broker that queues everything up so it can process everything as fast as possible and distribute that job across.  You have an indexer that looks at it as the analysis of, what is this log, how do I parse it, how do I tag it and where do I ship it and send it off to search and storage.  And then we have the pretty little web interface to actually monitor everything, sounds familiar to a lot of other products out there.  But the cool thing with Elastic Search and Log Stash is that you can scale it.  So instead of just having system, you know you may be logging ten gigs of data a day and then next week you’ve got to log a hundred.  Obviously the whole talk is log all the things. I’ll start on the ramble of sharing logs later but the more data we have the more we can do actionable intelligence for it.  So to scale it off all you have to do is take the little individual parts and split them across more systems.  So you can take a split the broker across multiple systems to queue everything up and have a little bit more redundancy.  You can take the Log Stash indexer split it up over multiple systems to actually process those logs.  And then your Elastic Search cluster will grow as well from the storing and searching.  Okay, so we're going to focus on the aspects of collecting and shipping logs, storing logs, processing, monitoring them and searching them, and obviously there’s that generating log.  So first thing is first the biggest reason that a lot of us don't generate the logs we need to is because we are using some commercial product and paying based upon how much we generate.  That doesn't work well for security and event monitoring because you start to get into picking and choosing before you get the intel.  We should build something that we can collect all the logs we want and the only costs to us is more disc space and more processing power which it's not relatively cheap compared to the other things.  And in order to collect the logs, logs actually have these thigns called inputs.  And we can use the traditional Syslog that everybody is familiar with.  The archaic Syslog of text and we can also leverage Lunberjack, which is the thinner version that can do the parsing of the data on the client.  We can also do time queries as inputs, I’ll touch on that in a second.  So going through the different systems you typically have to face for your Linux, Unix and Mac logs obviously you can leverage Syslog agents as is and send that data to Log Stash or you can also leverage the Log Stash agent which is JAVA based.  Now obviously you have to do that trade off of, do I want to install JAVA or do I just want to send it with SysLog?  It also supports TLS as well, so for those of you that are like, oh it will lose stuff, it's not encrypted it does support TCP and TLS.  The good old windows logs that everybody is making their money off of because there’s no good solution out there for windows logging agent. You’re able to do it with Log Stash agent again installing JAVA on systems or there are Syslog systems that are available, open source, free and community editions of them online.  So  ExLog is a great one that basically takes whatever you're sending it, files for windows event logs and sends it off to SysLog…same thing for the open source edition.  Both of these agents, Nxlog and Snare have commercial version, so before you go they have a paid version they also have an open source edition.  It just doesn’t have as much “pretties.”  Then obviously the third option for those of you who are banging your heads about the windows logs and how you can deploy this across your environment is to just use the windows build an event collector.  Using windows event collector with one windows system to kind of collect all those logs, use that central event collector system to parse the logs and then ship them off over Syslog.  That way you can easily deploy it with a group policy and not to have to worry about installing software on all of your production systems.  And then obviously the device logs, your network devices, your storage devices, your traditional Syslog works well but that's one of the cool things about Log Stash that it offers SNMP traps as well.  So you’re able to send SNMP traps to it and it’s able to parse that and push it into the logging complex.  You can send raw socket data and then I’ll be able to parse whatever is coming in and then able to make exec calls which I’ll touch on in a second. But most importantly sometimes we focus on the operating system logs and application system logs can get fed into Syslog complex.  But one of the biggest things we miss are these application logs.  So we need to log more than just the default, “hey, I requested this page.  Moving on.”  Leveraging web app logs and integrating into the web app code with your development team to generate, “hey I saw a password change, that seems weird and we just got a bunch of sessions that didn’t exist.”  Send something into the main logging complex and it creates a single source for you and the rest of the security teams out there to kind of monitor everything and so having all these different aspects to pull.  And obviously you can generate from those applications in text files depending on the application that you're using, file an event in SysLog or use Redis to queue up the logs and pretty much anything.  One of the things about Log Stash is the ability to pull from any source with your own plug ins.  That would be a whole other talk for a whole other day so we won’t’ get too far deep into there but it’s an option.  So what about the cloud?  So, more and more providers are offering cloud infrastructure and a lot of more people are moving to the cloud infrastructure are offering the ability to grab the audit logs without having to do a formal request.  So a lot of people aren’t monitoring this.  And recently, I'm trying to remember the name that had their AWS systems completely, poof. Code Spaces, thank you.  Code Spaces recently had  an AWS attach and we can argue over how their infrastructure was actually set up, they should have had their backups in a whole other environment that wasn’t AWS but we aren’t monitoring those logs.  We are pushing all our logs, not we all but a lot of places are pushing these logs and data out everywhere and not monitoring it.  We’re not monitoring who’s logging in to our google aps account. Somebody could be sitting there for months or logging in from some other geo location that doesn’t normally log into and nobody is checking AWS to see who has our API key that may have accidentally ended up somewhere, something seems weird.  So some of these services have started to offer the ability to actually take and grab these logs from AWS, Google Apps, Box, Sales Force, but others aren’t yet. So these are kind of a top gear top tip of different options for logging when you start to pull logs from these cloud services.  AWS has Coudtrail.  Thank you!  The gentleman is keeping me honest!  Thank you, sir ... AWS has mmmm trail.  Which basically takes event logs every five minutes and pushes we can send the log every five minutes and pushes them into an S3 bucket.  And Log Stash can pull those buckets and parse those logs and google apps has their reports API which is basically and API you can make queries against.  Box has their events API and SalesForce has their LoginHistory now. Correct me if I'm wrong but Office 365 doesn’t currently offer any live parsing but you can request them, but that doesn’t help you with monitoring it.  Drop Box, same thing, you can see it through their dashboard but you can’t have any kind of API access to it.  And Gighub I have yet to find any kind of logging other than enterprise.  And more and more people for some reason think it’s a good idea to push all of your enterprise code into Gighub.  I love Gighub, don’t get me wrong.  But I think that it's a bad idea to push everything out there.  So LogSash can pull from these from either an Exec or from a built in input.  Now you're going to be like you’re talking about all these inputs whatthey? This is a list of the current version of Inputs.  There’s a lot that are, we’ll call them Alpha and we’re touch on that later.  But there’s a lot that have been established, tested and well-rouned.  So as I said, you have Exec.  Exec will let you write any kind of shell script, and kind of ruby script, any kind of command whatsoever, take whatever the output is and you can send it into logging infrastructure.  And you can customize exactly how you want to get that log data.  If you don’t have a traditional source of data you can start querying other API’s and in fact you might see also on this list there's a Twitter plug-in.  You can have it monitor the Twitter stream for mentions of something, hashtags, whatever and put that into yur logging complex.  That’s pretty cool.  And like I said it has the S3 input, it’s got Exec and it’s got a few other things in there as well. So those are the different inputs. 
So as I said, traditional inputs you can still use.  The Syslog to collect events and Redis and all those other agents.  And the idea then is do you really trust a somewhat young product and I didn't mention that Log Stash is now a part of Elastic Search and their whole parent family so they have commercial support behind them.  Do you really trust this new JAVA based application with all of your logs all the time?  So yeah, if you're one of these people that live on the wild side like me, you can send it straight to Log Stash, like here have fun.  But you can also take and build a logging complex where you’re able to send these logs and parse these logs in different ways.  So my recommendation is that if you don’t always trust it you can always build up an Arc SysLog or SysLog or SysLog NG layer.  Basically send the logs to the log system first then send it to LogStash and also send it to UDP and send it to traditional filing for storage.  So you still have have that retention.  And you still have that log being archived elsewhere but you still have all of the cool new pretties that LogStash offers.  So once LogStash has all these events what do you do with them?  It’s kind of awesome and sucks at the same time.  It’s awesome because you can do anything with it ... it sucks because you can do anything with it and you have to learn how to do anything with it.  So LogStash decided to make this thing called, this parsing engine called GROK.  It still supports RegEx the traditional statements but GROK is pretty awesome as it simplifies not having to know RegEx.  They prebuilt all of these different syntax in here and I’ll go through examples in a second, this is probably just ten percent of them.  But if you want a map and an IP address, a log status level you're able to do that with just saying what the syntax is.  So you can just say “word” or “data.”  It makes life easy.  
So even those who are not super technical with RegEx are able to write a pattern this quickly to parse the patching logs.  And this is really it.  As soon as you get an input, obviously you need to have the input in there too but this is it for the filter.  Combine a patching log, done this is it, happy days.  What about more complex data?  The stuff that doesn’t really fit an existing syntax. Let's think of this as an example, we have a typical PAM notification.  This is raw sys log data that I generated August 8th.  You do the math.  Basically your typical, hey PAM detected somebody login.  Now, this may look a little complicated but I'm doing two levels of parsing here and this is an actual working config and I’ll be posting more later.  This is all you have to do in order to parse it.  First we parse to see, is it a PAgrab all the daM message, so we look for the PAM Unix flag, ta, pick which module, then what phase it’s coming from.  Is it authentication, is it authorization?  Then once you tag it you can see in there, there’s those add tags, add tag for PAM, add tag for login so you can do filtering and bondering for it.  Once you tag it with that you can easily say alright let me grab all the other data out of it.  I want to grab the user, the session ID, I want to grab the remote host.  And that’s it for the RegEx and it gets parsed.  And you’re able to take and here’s a quick from Elastic Search parsing into all the different fields and without having to know all of this crazy RegEx to figure out we have a missing case here.  You’re able to quickly say, alright grab the data and put it into this format and its pretty easy to figure out how to start parsing and filtering your logs.  But that’s not all the filters it has on the way in.  We can tag metrics with it.  We can track to see, alright lets grab everything that has a failed log in and assign a metrics to it and know how many failed log ins we have for this IP for this user over a 1 minute, 5 minute, 15 minute, 1 hour window.  We can get you IP information with the filters as well.  Those pretty graphs that your bosses love. I don't know why people love to see that we have a bunch of attacks coming from this other country.  Did they get in?  No, but we have a bunch of attacks.  You’re on the internet bro.  But management for some reason loves that, you can give them those pretty little graphs.  You can do GYP tagging and pull from the GYP databases.  You can do reverse DNS look ups to be able to make your matches easier if you have a dynamic environment or just want to start logging that data. And then there's URL decode so you can take a decode if you have a URL inside of a URL.  You can do multiline data so if it crosses more than one line.  You can do key values so if it’s a situation as you saw in the previous one of our host equals, action equals you can just key value it and it parses automatically.  And then the coolest thing is it can do anonymize.  And if you happen not to be here in the United States and have to not store data of people you can anonymize that data as soon as it comes in with random data or hash data, however you can take and sanitize that.    So those of you who have to deal with European laws or other laws that say y can’t restore this after so long, great option.  So after you filter that data, LogStash can output it to pretty much anywhere.  Traditionally people will send it to Elastic Search for monitoring and searching.  And that’s what we’re going to cover next.  But you can send it to different indexes just like you can with other large logging products.  You can also do what’s really cool, it’s called Exec.  So with Exec if you see a certain set of flags or you parse it out and filter it out you can take and go, oh this looks interesting.  I want to do something every time that I see this.  I don't want an e‑mail; I want it to automatically block something.  You can just make an Exec call to whatever script and I’ll touch on some cool things later. If you are like me and you don't want to keep changing your filters and want to dynamically change how things are, you can make a simple web call to some other monitoring app that you wrote and say I saw a bunch of odd things or saw a log in from this IP.  Do something with that.  And write up a web app, instead of having to script and write up all this stuff and keep restarting your filters you can just say send all this log in information to this other web source and tell me if I should generate any kind of alerts.  And if you’re somebody who HipChats all day you can send it to your chat logs.  I don’t think there is an IRC output which I was kind of disappointed in.  If you’re a user of PagerDuty you can send it there or your traditional email notifications to go in that bucket you never monitor.  Appliance vendors, a successful log‑in, and if there's too many failed log‑ins and then you can scale.  So as I was saying you can filter you can parse.  You can do all this fun stuff.  What do we care about?    We’re sending it to these places and we’re not monitoring it.  The biggest most important thing is for us to actually monitor these security events.  So as I was saying we setup filters and parsing and stuff, we tag them saying this is a security event this is a compliance event, this is a failed login a success login.  We can create all the tags you want. Add metrics if you want to see if there are too many failed logins over a certain window.  You pick the output and then you can scale. So here are two simple outputs that I wrote together real fast that shows if it's a failed login and if it's been over two for this specific user within a minute, send me an email.  That’s how simple it is (whispering) and if you want to send it, like I was saying all the auth requests, you want to send it to some other source to dynamically determine, hey I wrote this cool little PHP app that will tell me, if you send the IP and the username it will determine if it’s new.  If you’re comfortable with some other language, RUBY, or whatever send it there. You can start sending all these kinds of actions elsewhere that traditional logging complexes can’t do.  Yes, some commercial products have worked as well, but this one is free.  So then the second example, obviously anytime there is an auth request that’s tagged as an auth request after we do all of those filters, send it to whatever.  That’s not actually real so don’t go trying to query that you're not going to get anything.  So as I was saying we can do these Execs, we can do these remote calls.  As the security people this is awesome.  We can have it do whatever.  We can have it update, this is for those that like to live dangerously on the edge.  You can have it automatically update firewalls, ACLS, switches, oh I saw somebody new join the thing.  I don't have a traditional NAC complex, so go ahead and tell it to disable the switchboard.  Ok cool, Exec, dun duh dun duh dun, wrote this cool script, done.  You're able to do that with this new logging complex.  Notifying user directly, hey somebody logged in from a new IP address and this looks weird or it’s not from within the U.S. or whatever country you’re from, hey this is weird for them, let me send that user an email and make it their responsibility to go, hey security something is up, I didn’t log in.  You don’t have to monitor that all and you can start using your logging complex to generate those kind of alerts directly to your users.  Obviously notify for admin logins, both on the internal and external side.  One of the greatest things (indiscernible 30:40) will talk about it, oh yea I got admin on all these systems, oh yea I crawled across the environment.  Why aren’t we logging and detecting that?  A lot of admins shouldn’t be logging in remotely typically and why not generate events for people to follow up?  And then obviously for user log ins on new machines, hey Jim doesn’t normally log in to this machine and I haven’t seen this before, I’m going to generate an event.  And this is easy to do then with these filters with these custom outputs that some other logging complexes don’t support.  So again, we’ve got the monitoring; we’ve got the collection and the storage.  What about the searching?  That’s one of the biggest problems on traditional Syslogs is that you have to write, run through this text file, wait, wait, wait, 10 gigs, come on give me something.  So since it’s based on Elastic Search, the crew over at Elastic Search, this complex has a pretty little front end called Kibana. Kibana pretty much looks like every other logging searching thing you can ever imagine.  And you’re able to quickly search for the events, correlate the events.  I'm not going to go too far into Kibana because you can create all these pretty custom dashboards.  You can go through have the pretty graphys for the management.  Your boss loves them.  Do this for your boss to get a better job.  But no, or get a raise, sorry.  But this works great ... but that's the pretty dash board, you can do all the searches, but really like I said we are focusing on the security side, getting those alerts, getting those notifications.  But you may be going, for those of you who know what Elastic Search is, is maybe going dude, uh elastic search, really?  This shit doesn’t have any security control whatsoever.  Yea it doesn’t have security controls whatsoever.  You would have to build them.  So as I said it's not an easy solution but it’s one you can scale and customize greatly.  So Elastic Search is made so that basically you can cluster with everything, multicast to figure out all the peers.  It doesn’t have authentication and just trust everyone, give every one pseudo rights, yea it’s bad from a security perspective.  But it’s great from a data perspective.  So we have to build in these security controls on top of that.  We have to write an nginx proxy in order to bind locally, really simple config.  Have to segment this stuff off on the network so it doesn’t take and multicast everywhere else.  Again, simple change and you have to enable to logging on you nginx that you’re doing the proxy for, for compliance reasons and for the tracking of that.  Again, simple configs but people are like oh, you can't use that because of security reasons.  You just have to add a few additional controls. Now, from a performance side you can tweak a lot more when you built your own system.  So you can take in and tweak if you are starting to scale up the size of your indexes, sometimes by default LogStash and Elastic Search do daily indexes.  But if you start logging 200 gigs a day, a 200 gig index is kind of a bad thing, so you can start to change the size of your indexes to hourly, minutes, so on and so forth. You can increase the number of workers in LogStash in order to parse that stuff faster.  You can enable compression in elastic search.  And you can enable queuing for the network traffic coming in.  And the whole point of this is so you can scale.  In traditional systems you can’t scale, you can’t cluster, it’s not tolerant.  You can easily scale up with LogStash, elastic search and Kibana by cleaning up more instances of Elastic Search.  And as I was saying putting more steps in front of it that can kind of distribute and spit it out and they recommend Redis. Works well if you LogStash in front of LogStash.  I know this doesn't make sense, but it does.  So the question is:  Is it as good or better than the vendor?  We are up here preaching, you should look at open source stuff and you should take and do something different than just buy a product.  Is it better? It's your call.  If you have a technical ability, a team with the technical ability or coworkers then yea it works well and doesn’t come at the licensure costs of other things. But it's not as easy to manage as a paid solution.  It’s still   relatively young so there may be bugs that you encounter.  So if you’re sitting there with critical logs that you cannot lose at all you may want to look as somebody who is more established or like I was saying add a few steps in there and send it off to multiple storage locations.  It lacks authentication out of the box, it’s something you can easily change but you’ll hear people shacking their stick at that saying, you’ve got to be able to authenticate to it, nginx proxy, HT password, done. But on the plus side it's extremely customizable.  The price is just right and some enterprises support is available.  And you can even use it in the cloud. 
(Cheering) 
I had to wet my whistle there.  So what's next?  I just rambled here about how great this thing is, what’s next?  We have this thing we call the Open PCI Project, the domain hack PCI also works for some reason, I don’t’ know why.  But basically the idea is there shouldn't be any secrets as to how to secure stuff.  People have been selling this whole magic bean of oh we can give you these configs and keep reselling them.  They’re configs guys, like we can share that info, it doesn’t provide any competitive edge and in fact it just makes things easier for all of us.  So we have this thing called the Open PCI Project, it needs an update for all of this stuff but I’ll get that soon.  As soon as possible.  Okay, but basically to take and share this information and share all the configs, all the base parsing a VM that’s ready to go that you just spin up right away.  And obviously the hardening guides, Elastic Search, insecure by default, some hardening guides to just, here paste a config, it works, great, awesome.  To make it as close as similar to these large commercial projects but obviously you need a little more hands on support.  So with that I'm ending a bit early, I’m sorry. I’ll let you guys get in lines for the next talks here.  But that’s me, that’s the talk about all that stuff, all in all log stuff.  Fuck the companies that sue people or “legal pressure” for giving talks about stuff they don’t want and that’s it.  Thanks all!