Presenter:
Transcript:
Okay, so I know the title is a little bit vague and obnoxious because that tends to be how I do titles for talks. But hopefully you're here to talk about or listen about how to deal with the hype cycle that comes with CD's about to draw up, or things that people find and what to do with that, how to get value from it.
So first up, who am I? Why am I talking about this stuff? First up, I am a total gearhead. About way more things than I should admit to music stuff. I was just talking mixers and I'm a little jealous of that one. Guitars. All the keyboards. Any Q amp Xbmc people out there? Or am I just really exposing how big of a nerd I am?
Yeah. Okay, that's all right. I travel with the split keyboard. If you want to know, just ask. I am an obsessive learner. I started in academia and got bored after I got tenure and decided I'll never get bored doing cybersecurity, so I'll go do that. And it's true. I haven't gotten bored yet. And then most of my focus right now is deer and threat hunting.
And I am really intentional, intentional about including the air and not just calling it death or DNR because I think the all three really need to go together. Is anybody in here just a pure analyst, SoC analyst, just triage. No. Okay. So if all you do is write detections, your analysts probably don't like you very much because in my experience, people who only write the detections and never have to deal with them on the back end tend to give you vague titles and a lot of information that you can't immediately take action from.
This happened something, did something, and it's like, well, what's the context? What else happened around it? And if you've worked in a small shop where you're responsible for all of the things and you write this and then you triage it, you kind of hate yourself because you're like, why? Why did I think seeing somebody logged in was sufficient?
Because now you have to go digging and find out why you thought this was important enough to detect on or fire an alert on. And when you've set it up to go off in the middle of the night, you really, really hate yourself. Not that I've ever done that, but it happens. All right, so who are you people?
Anybody out there? Massively experience detection engineer. Okay, so some of y'all, this will be seriously old hat. And you can feel free to correct me or think I'm crazy. Probably both. Anybody who really wants to be a detection engineer trying to get into that space, learn a little bit about it. Okay, good. SoC analysts we just established.
Okay. So we do have some people who are dealing with the result of what we write and just. Yes, you're here because you had to find something to do at 11:00 on day two. Yeah, a little like I don't know what I'm doing. There's was coffee nearby, and I stumbled in. I got lost in Georgia Brown. I've gotten lost both days already.
I still haven't gotten this place figured out, so there should be something for everybody. Because I sometimes think my background in academia is a benefit. Sometimes I think it's a drawback because I do think a little bit differently, approach things a little oddly. And it's just it's it's fun. I'm one of those weird people that you get into the air thing.
And I've been told, like, we please turn off your camera. You look entirely too happy while you're doing this, and you're freaking the compliance people out. And I'm like, no, this is awesome. All right, seriously, I need you to look like you're concerned. I'm like, I am concerned, but this is fine. And my boss is like, okay, I need you to, like, chill or turn your camera off.
I'm like, camera off because it is fun, right? Do y'all have fun and air situations or am I really just. Yeah, the people who are really are people are like, we don't want to admit it, but yes, it is super fun. And everybody else looks at us like y'all are crazy. Yeah. It's fun. It's it's like a competitive sport.
And I think that's part of why I like it. So if you want to go hands on because we will. Depending on how many rabbit holes I decide to go down and how fast I decide to talk, we should have a good amount of time at the end to do some hands on stuff with this. But if you do want to go hands on, we're going to use the Panther analysis repo.
So however you clone things, go ahead and pull that down. You do need Python, so you can pip install the Panther analysis tool. That's your information. I'll give you a little bit of time on this slide to pull the things down. A couple things about why we're using this. This is a publicly available repo, has all of Panther's detections in it.
They're, some, Panthers detections are Python based, which means you can do a lot of ridiculous stuff with it. All of your exceptions can live in one place, and you can import them to all the detections that you need, and you can change them. And then they're changed everywhere, which is incredibly nice. For those of you who have experienced the pain of having to go detection by detection and change all of your exceptions.
And I'm sorry for those of you who I've just given massive flashbacks because it's not very enjoyable. If we had, a longer extended time period, we'd also look at setting up scanners, tools to do this. That's a Yaml based one that if you are a sigma rule type person, that's a good open source option. They've got a couple different repos that you can mess around with.
Practice detections. And then one of the reasons I like both of these, for people who are working towards detection engineering, because both the tools and the rules are public, you can see them, you can test them. You learn a lot about how to write good detections and then how to also test them. Because for me, as a detection engineer and the response person, I never wanted detection going into production.
That has not been tested thoroughly because alert floods suck and it is not fun when all of a sudden you've got a thousand alerts in ten minutes, even if you know they're all fine and you're just having to close them because you messed up your logic or you messed up your exception, it takes a lot of time to dig through all that.
So unit tests matter, and both of these give you the option to do that and check your basic logic. Okay. Are we good enough to move off of this slide. Everybody's at least got a screenshot of it or something else. And if you don't have the tooling at your work to start applying these and you're really wanting to get hands on both of these, you should be able to make contributions to start showing your experience.
As someone who career switched, being able to do things like that really can be helpful as you're trying to show experience when you have none and everybody wants experience. All right. So first up, I hope you enjoy my happy little dumpster fire. For some reason, I did not want to give me a depressing dumpster fire. Everything had woodland creatures and a happy sun.
No matter how bluntly I ask it to just give me a dumpster with fire in it. So we're going to be happy about our dumpster fire today. But what I mean by this. Who remembers the open? SSH vulnerability a couple years ago? That it was like the world was going to end when that vulnerability dropped, right? Like we were on slack, like, does anybody know what's going what is happening?
This is supposed to break all the things. All of our SSH boxes will be pwned in the first five minutes. When this drops, we're digging through the commits. We're looking at the git log, trying to figure out what's going on. These teasers are dropping about how bad it's going to be.
The impact estimates were massively overblown. It came out, we're reading this stuff and it's like, really? You have to have this very specific configuration, which if you had in your environment, I'm very sorry it this did suck for you, but pretty much nobody that I talked to had it. And it was a little frustrating to deal with the hype.
And then the drop where we're like, oh, this is going to be fun. And then it was like, well, that was boring. I mean, there is yay, we're not in trouble. But in the rush to identify the IOCs, the indicators of compromise, get the information, dig through it, look at the revision, see if it changed the impact any.
There was the yay! This doesn't matter. Also a little disappointment because we like what we do and it's a competitive activity. But it's also not great for our cortisol levels, right? It's not good for your sleep cycle. It's not good for your stress levels. So how do you manage that cycle right. Especially with the news and the ridiculousness as things go right now.
So managing it.
Please work with your compliance teams or your legal council or your comms people, whoever they are. I hope they're not. Also, you to set expectations for security inquiries. I really love getting asked about were you impacted by the CDE when the CDE won't be out for a week and I'm like, I don't really know how it's going to impact us because it's not out yet, but you can't really go back to the customer with that.
So work with your compliance teams and people who feel that to have some sort of a SOP for how those will be handled and preferably not making their way to the people who do the investigating and make sure everyone understands it takes time to get impact. We know people get scared when these things come out, and some turn into pretty big deals like log for shell.
Others don't so much take the information that you can to establish relevance. Right? We'll get asked about things and security inquiries that have absolutely no relevance to your environment. If you know that and you're getting security queries, go ahead and say it. We don't use it. We're fine. Please don't ask us again and then you'll get asked again.
But that's okay. Think about the criticality. Is this in prod? Is it just in dev environments? Is it someplace that's going to be easy to exploit. Or is it six layers deep? How hard is it going to be to patch. Right. Do you know which of your systems, which of your pieces of code? If you patch or you update, you're now going to have to go and do a whole bunch of cascading things to deal with breeze.
Get your popcorn, find your people on slack, get your groups where you have the support so that when something happens, if it is a really big deal, you have people to ask questions of. And if it's not a really big deal, you have people to laugh with because there's a lot of craziness in our field and you need both of those things.
If you feel the need to take action. There are always hardening actions that you can take. You can always look to see what logging and monitoring are in place. This is a time that, depending on what it is, I like to take advantage of the hype and be like, well, you're right, this does sound scary. I would love to tell you what's going to happen with it, but you decided that we didn't need to pay for logging on that, and hopefully you've got the risk acceptance with their signature on it.
That said, we don't think we need to log this or it's not important enough. These can give you some leverage to get things in place to help future problems, and you can figure out what might happen and get your plan in place. Don't spend a ton of time on this because we have things we're supposed to be doing.
But if you know that you're under pressure and you know you're going to get questions about it, it's not a bad way to spend some time. Game planning is not bad. Pre-planning is not bad. But don't let the hype cycle dictate your workload. Is. That's what you continue chasing. It's really easy to forget about your critical path and just chase whatever's in the news every week.
All right, so let's talk about the aftermath. What happens after the drop. The stuff comes out. Now, what do we do? We do what we do with anything. We investigate, remediate, protect and put our detections in. So first up we do the investigating, read the original research. Don't just go to the Hacker News blurb. It's not going to have the details you need, right?
That's what most people will read. But you do need to know when something is over your head and when that happens, know where to go. I look at Huntress stuff a lot. John Hammond stuff is really good for breakdowns when things drop. Datadog has good breakdowns. Splunk often has good ones. Am I missing any that you all have as go to sources for breakdowns?
Now classic elastic is good if we want to talk pregame malware archeology cheat sheets are is really helpful. Since Michael's here, I'm just saying.
Then figure out the real impact. Do you actually have that configuration in your environment?
If not, do you need to be concerned? Maybe. Maybe not. Is it like six layers deep? Is it is it just on your CEO's computer and nowhere else? Right. Because they have admin. Because they need it for reasons. Figure out your impact. Assess the damage, do what you know how to do and document the everything out of that.
Right. This is where your EIR documents are very important, that you have all that stuff laid out in a template so that you don't forget things, and you take all of the notes, all of the screenshots, because things that get hyped up, get increased scrutiny, and you need to be able to cover your assets, so to speak.
All right. Now we're on to remediate. Can you patch it? You don't always have that option. You may be running a framework version that you can't upgrade your database version. It happens. Or vice versa. You may be stuck with it. And if so, how can you remediate? Can you get both patches done with testing in a reasonable time?
What compensating controls can you put into place? How can you protect yourself in the meantime? Can you just get rid of it? That's my favorite, right? This thing has a problem. Well, it's in this library that is used in one place. Can we please swap that out with the same library that's used in every other part of our code?
Am I the only one who's seen that? Like some somebody had this one special library they liked, and it's just in there. Little tiny piece of the app. I feel like I've been traumatized and nobody else has seen this. Things like that, though, can be a lot easier to deal with. Like, I'm sorry that you don't like this time date formatter.
This is what we use everywhere else.
Unless you can give me a really good reason why we're using it. Standardize, please, for everyone's sake. And then what else do you need to do based on the impact? Is there going to be additional fallout? Do you need to do for real cleanup, and how are you going to handle this from an overall ER perspective? We can admit as security people at this day and age, most of these things are not going to be that big of a deal.
I hate to say that I really hate to say it on tape, but most security breaches most security events. If your company is of a decent size and robustness, they're not going to be company enders. If you can manage the initial fallout, that's 30 to 60 days. If you can get your company through that, you're probably going to be okay.
Can you identify things that are company enders before you get to that point? If you can, you can typically write out that remediation stage. All right. Now we get to the protect stuff. This is where we're having a lot more fun in my world anyways. The hardening in the defense in depth. You started figuring out what's happened. And now we get to start looking at how we can make the future better.
Where can you take the lessons we've learned and put them into practice? Where can you put additional steps in? And this may be part of your remediation depending on what you have going on. Okay, all of this is pretty standard stuff, so I'm not going to spend a lot of time on it other than this is ongoing and in your remediation steps and in your IR steps, please take those after action items, take those action items and don't let them go into the ether.
How many of you have a backlog of er wishlist items that has things from years ago? They're like, we're going to do this and they just kind of flitter off into the ether and get forgotten about, right? That is one of the things that after a year or so, started to really great at me, find a way to track them.
Whatever project management tool you use, tag them, link them to the causing incident. If you really want to go over the top, which is me, set up a bot that will remind you and nag you when those action items have not been touched in a month or six months, or they're blocked so that you cannot forget about them because it doesn't look good when you have another incident or another investigation and you come up with the exact same action items.
So anybody been there? We're like, we should do this. You're like, it's in our backlog. I have no comment. Yeah. There's a there's a lot right that we need to do. And when they keep coming up this is when you can prioritize them. And the other thing with that is just like in our detection and alert titles, be specific what you think you're going to remember when you write that action item down, you are not going to remember be incredibly verbose, like five V's level of verbosity, because what you have fresh in your mind right now, when you come back to it in a month or six months or another team picks up, they're not
going to know. They don't want to look in your head and you don't want them looking in your head. So put all of those details in there. It's even better if you can assign ownership at the R or the after action meeting, right, and get those on a specific backlog. So that gets through the kind of basic stuff.
And now we get to the fun part where we get to write detections. Ideally with this we're going to go higher up in the pyramid of pain. Show of hands. Pyramid of pain is familiar to about half of us. If not, you can do a quick Google starts with hash as very volatile changes with letter. Super annoying to rewrite for all the time and goes up to TPS with an aggressive capital.
There should be lower, but I was being aggressive apparently, and we want to focus on the higher end. I will say that sometimes when you've got something in the wild that is being consistent with a lower level TTP or with a lower level indicator, it's fine to write something for that, right? Sometimes we want to alert on IPS, or we want to alert on a domain or a hash.
There are times that that's a worthwhile detection. When I'm doing that, though, I want to put those in a single place that I have single file, and it's easy to edit right and have. I would highly recommend commenting why it's in there and giving it an expiration date, because otherwise they go on there and they're still there five years later and nobody knows why.
It's like, why are we alerting on this random ship that's showing up in my logs every day? So anybody seen that the log for J or the log for show ones did that forever. And some alerting platforms were like, that was two years ago. I don't want to see that anymore. They have rotated. Please stop. Make it some place where you can rotate, give them and give them a life and get rid of them at some point.
All right? All exceptions should have a lifespan and a review span. Make sure that you note that other things to think about as you're doing this. What level makes sense? Who remembers the snowflake thing that was like two years ago? That was all the panic about. Snowflake is vulnerable and everybody's getting in. That was a pretty high level panic, right?
There was a lot of speculation about what was going on and what did it turn out to be. So anybody remember? Crud. Stuffing. Crud. Reuse. Not on not on snowflake. They have gotten way more aggressive about making their customers turn on to a for now, which is a good lesson for all of us. But what level makes sense that one had a very, very unique user agent that I would feel comfortable using as a detection indicator.
Now, it's not safe for worker family, so I'm not going to say it, but you can Google and find it. Are there existing data detections that can be modified? Do you know your detection corpus? Do you know what's in your detections? For those of you using a SIM in your everyday life, do you know what the logic looks like behind the detections that you see?
Can you off the top of your head, think about how you could look at indicators of compromise and what detections make sense to add them to, or to clone and edit? Yes. No. Maybe. That's really important. That's another good thing about detection is code. When you have your detection in code and you can search for repo for event names, users, things like that, it makes finding your detections that you can morph way easier than when they're just in a UI.
I'll not soapbox on that because we would be here for way longer than we have. But detections as code can make this cycle a lot easier. And are there any exceptions needed? I can pretty much guarantee you the answer is yes. There will be exceptions needed. Please do not put a detection in the prod without looking for those exceptions, because you will regret it a lot and not be very popular.
If you're not the one dealing with the aftermath. So find the exceptions, finds what's normal. And this is where the in-house security team becomes so important. You should know what's normal in your environments. When you start looking and doing your log analysis, your threat hunting type activities to find your detections to make you know what's normal. You know these user agents, you know these usernames.
You have an idea of the context. So as you're building your detection, you know, okay, this is what my exception needs to look like. Or, you know, you're looking at it and going, oh crap, that's not this. But this is also not good, right? Sometimes you're looking for something and you find something else that is also not good.
And then you get to go on another fun adventure. So that's where we're going with the detect piece. And now we get to have fun. So in.
The if you do a quick web search for tales from the Cloud Trenches, the attacker doth protect persist too much. This is where we're going to kind of go hands on for a minute. We've been far enough out from the snowflake thing that it's not as fun to do. This one's relatively recent, and Datadog does a good job with their writeups.
Giving you all the pieces that we need to do detections. So if you want to do the hands on piece, you can go ahead and find this, article. If you don't want to do the hands on piece, you can just kind of hang with us as we walk through. Okay. So once you've got this, article up, just do a quick scan.
And what's really nice about Datadog is they tend to put like a cheat sheet at the bottom with. Here are some detections to think about from this that don't just go straight to the treat. Cheat. For this I totally do. When something actually drops and I need to make it detection, but not for this. And while you're finding and starting to look at that, a couple things just to manage all of this stuff that you need to manage, I use an app called reader and Readwise that I highlight in, and it will export my highlights into obsidian or other markdown formats.
So I can then share that with teammates. I can share that with other people. So if we need to get things made or I need to get them up to speed on something, I can just give them the bullet points essentially of things like this to get the detection made and get on our way. So personal knowledge management, PKM is a really big deal.
And for for what we do, dealing with ridiculous amounts of threat intelligence and ridiculous amounts of things that we have to process and keep a hold of. If you don't have a system for managing the things you have to remember strongly, consider how you can do that. All right, so everybody have the article who wants to find the article.
Yes. No something. We're sleeping. It's time for lunch. All right. So just flipping through it. What is like an easy indicator, something that you might want to do a quick log search for that would be unique.
So I know for me one of the things that popped up, was the naming of the lambda function there. There was a lambda function named buckets five, five, five. Does that fit anybody's naming convention? Do you know what the naming convention is in your environment? Can you regex that into a detection to alert on anything that doesn't fit that?
Does that make a more robust detection then searching and making a detection for buckets 555 does that kind of make sense and how that approach takes an initial indicator and then expands it for your environment? The other benefit of going into something like regex to look for things that don't match your pattern. We have environments where people can pretty much go nuts, right?
And you have ridiculous sprawl. We don't so much care about that going on in that environments. But you do have prod environments where you want everything neat and tidy. Applying a detection like that to prod, and anytime something gets spun up that doesn't match your normal convention, and getting an alert on that can be incredibly helpful, because then you find out you have permissions that I did not think you had.
Right? Have you ever found that when something weird gets turned up and you're like, how come you could do that and you find lingering permissions or other things? It's also useful to start tracking down resources that you just don't need anymore. Things that got spun up six years ago for testing and never got killed, right? Nobody has that in their environment, just me.
Now, things like that happens. And then looking at role names, role attachments, same thing as you can get your environment. If you can get your organization on board with standardized naming and infrastructure as code to deploy that, it can make your life a lot easier. And then anything that goes outside of that, you can detect and identify problems.
All right. Anything else as you're going through that looks like something that could be fun to detect on or interesting things that you might not see in your environment.
What about, SMK Amazon aws.com? Is that something you would want to alert on? In and of itself, please say no. That that in and of itself is going to be crazy loud. But could you alert on disabling AWS service access? Yeah, especially from unknown people or from outside of a certain group and disabling things that you want enabled, right.
Those are things that help keep your organization secure. So any of those likely should light up like a Christmas tree because you have those in place for a reason. And those are also things that if it does happen, you should know it's coming, right? There should be a ticket. There should be something telling you, hey, we're going to change this.
Group's called secure user called secret. That goes back to our regex for naming again.
If you look down at the detection opportunities.
I like this because it gives you some different things to think about. Okay? Creation and modification actions of a log in profile. If you have the Panther repo still up as you were doing this, you can search in that and plug in any of the things we've talked about. Right. So you could search for log in or profile in the repo to see if there's a detection that you could build off of that.
If I remember right, there should be. You can look for administrator access has full access. Any of these things. How do you feel about alerting on unusual login locations? Geolocation of IPS depends on the how do you feel about impossible travel alerts? This is a that's like a hot button item. It's a good signal. Is it always a good signal?
A VPN can be problematic.
Okay, so last week this this is my favorite false positive ever.
I get a detection impossible travel alert. This person logged in from Europe at this IP.
Two hours later they logged in from Dallas, Texas at this IP. Y'all. It was the same IP at home. Like I'm sorry, what?
I'd seen it before, but something was going on last week with the geolocation info. I was I was getting just repeated same IP, false positive. I'm like, well, either somebody is doing a campaign to really mess with some geolocation activity. Or I don't know what's going on. But that's also something that I knew because I had my IP in the detection title right.
It it came through right away and I could see.
That that IP is literally the same thing. Why is this alerting something is messed up. Does that mean I just ignored the alert? I know I panicked at first and went what the heck? And went digging through the logs to make sure everything looked okay. After the third one, I was like, okay, somebody is having a bad day.
We're not going to worry about that too much. But it's it's things like that that give you the context that make this signal kind of interesting. And can impossible travel be a really good signal? Yes. If you have a company with a single base, really strong signal, if you have a remote company that does a lot on VPN, it can drive you crazy.
Can you allow list IP? Can you do things to make it easier? Can you make it into a good signal? Yes. Are there still times that it's going to make you a little wondering what your life is about? Yeah, but that's also what saved queries and enrichment automatically. And our automation is for. Okay, what about fun things like getting Federation ticket tokens with high privileges?
Do you know how to look for that?
Can you find that in your logs right now? This is this is the other like game. I like to play with myself as I'm going through this is looking at this and going, do I know how to find this in my logs right now? Can I go and identify that? Can I go find this without having to go look at what the documentation is like?
Do I need to go to the schemas to find these things? And then at the end you've got the full IOC list which is really helpful to do your threat hunting. Right. If you are in the middle of something and you know that you've got these things in your environment, scrolling down to those IOCs to do your threat, hunting is very understandable and a very good idea.
Okay, does anybody have something out of this article that they would like to talk about? Look at? Did they find a Panther detection that the you want to modify because you could go modify it and submit a PR and they're slow to approve sometimes that you it's a good open source contribution.
Nothing on that. All right. So the other thing that I will say on using this approach, don't just look at it as what can I do to deal with this problem. Think more about what can I do with these kinds of problems. We we want to think at a broader scale than just dealing with the issue at hand, because we we don't want to make detection after your detection, after detection, that address very slight variations.
Right. We want to make very robust detections that we can use to identify categories that we can use one detection for multiple things. And then have your alert context have your enrichment that comes through. Fill in some additional information so that when you get it on the other end, or your analyst gets it on the other end, they know what needs done and it is totally fine to have detections firing.
Just to give yourself operational context, right? Sometimes, especially if you're new at a company, turning on detections on certain things so that you know what normal looks like is totally okay. You may not want to do it very long, and you may want to set them to like a low tier that won't page you on the weekends or nights, but it can be a really good way to get familiar with the environment and learn what's going on without having to have dedicated threat hunting time.
Because a lot of us are working with lean teams, and it's hard to dedicate time to threat hunting. Makes sense. All right, so with that, any questions items for discussion, topics for panic. I haven't seen any reason to panic today, but I haven't gone through all of my hours yet, so I may have missed something here. Is everybody ready for lunch?
I haven't heard what lunches, so I'm super curious. I hope it's food. It may be coke for me, but there will be food too. I hope.
That, That was scary.
Announcement. That one was crazy. Did you read that? One says anything that says Cisco to me is always equal parts interesting and terrifying, because there's so much Cisco stuff out there and so much of it is legacy and not getting updated ever.
So yeah, well, power went out for those people that everything expired yesterday and feel for that. But Windows 10 security updates in Europe at least may have to be free for a while, so they've got that going for them. We're kind of out of luck, but we're all on Macs so we don't care, right? Yeah.
I'm sorry. This panzer, this panther. Now, is this deal, is does it only, work with only Python? Could I integrated with maybe C sharp or not? So, the way that the panther. So Panther is a sim, as a company, and their detections are written in Python. You can write them in Yaml like they have a basic format in Yaml.
I don't think you can integrate it with anything else. That's just the language that they, they use. Okay. I don't know of any vendor using C sharp for detections as far as I know, detections are basically Yaml, SQL ish, SQL, Json, pipe languages, and. Yeah, Yaml, Python, SQL ish. Did I miss any like every database like, exception?
Sorry, XML, I can't I refuse to acknowledge XML. Also Json. I will take my data in Json. I would much prefer my logs come in Json versus XML, but I would prefer never to write my detections in XML. And doc options are expanding for foursomes, but it's still not. I think the standard we're seeing more of it, but it's not everywhere yet.
But if you wanted to write a SIM that worked with C-sharp, I think you would have some barriers to entry, because security engineers are typically not known for their desire to code in anything but Python. And maybe rust. I think rust is gaming. What? Or PowerShell? Yeah, well, since PowerShell got ported. Yeah, PowerShell is phenomenal. If you don't know PowerShell, learn a little bit. It's so much fun.
Yeah, rust a little bit ago. But mostly Python is is where it's going to be. Any other questions comments.
And that's where you can find me. I'm not since X became X I'm not on there very much anymore, but I occasionally am on both and infosec exchange. And then LinkedIn is pretty, pretty easy to find me. But thank you all for coming. I hope you're enjoying the conference and enjoy lunch.
