[00:01.460 --> 00:07.640]  Yes, this is your epilepsy warning. Close your eyes for the next 25 minutes.
[00:30.940 --> 00:36.440]  I'm just going to run it like this. We will make do, because I think we might be running behind gang at this point.
[00:37.100 --> 00:42.440]  Alright, so we're going to talk about the basics of threat intelligence.
[00:42.640 --> 00:47.660]  And the goal of doing the basics of threat intelligence is it gets very over-complicated.
[00:47.660 --> 00:51.860]  Because it's never boiled down to its very base before we get into it.
[00:51.860 --> 00:56.820]  As I've been told growing up, it's like learning to fly before you've learned to crawl.
[00:57.420 --> 01:05.560]  So, with threat intelligence, we're going to get to the guy who's actually talking about threat intelligence today.
[01:05.820 --> 01:11.640]  Now, the handle is Man in Black. I've been at InfoSec for 10 years.
[01:11.680 --> 01:20.100]  Companies as small as 3 to 10,000 or bigger. Experienced in quite a bunch of industries over that time.
[01:20.300 --> 01:24.000]  And right now, I focus on incident response and threat intelligence.
[01:24.000 --> 01:28.280]  Now, from the idea of a misunderstanding like we have with threat intelligence,
[01:28.280 --> 01:33.240]  when I requested to speak at CypherCon, Mike came to me and said,
[01:33.240 --> 01:40.160]  Alright, we want a handle. This is a hacker conference. We want to feel like hackers.
[01:40.500 --> 01:45.160]  Well, looking at it, I submit this. I go to the website.
[01:45.260 --> 01:48.000]  I'm the only person who is not identified by name.
[01:48.000 --> 01:53.000]  And I'm the only person who does not have a Facebook-style picture out there to identify who I am.
[01:53.480 --> 01:57.960]  So, like threat intelligence, we're going to start from that misunderstanding.
[01:58.720 --> 02:03.840]  I had an idea of what I was supposed to do, and I did not skip the landing at all.
[02:05.060 --> 02:12.160]  So, looking at threat intelligence, my whole premise was we need to boil it down, as I said, to as simple as it gets.
[02:12.440 --> 02:18.040]  Now, in my pre-IT life, I worked for a very large printing company here in Wisconsin.
[02:18.040 --> 02:21.900]  And the owner of that company, with its worldwide footprint,
[02:21.900 --> 02:30.920]  boiled his entire printing operation from plating, press, finishing, shipping, quality control, to three words.
[02:31.060 --> 02:36.280]  Ink on paper. That was his entire business model that he ever explained to anyone.
[02:36.760 --> 02:44.220]  So, transferring that to an IT standpoint, we're going to take a slight detour and talk about the cloud.
[02:44.880 --> 02:52.120]  And in a presentation where we're trying to skip past buzzwords, I apologize for opening with one.
[02:52.380 --> 02:58.880]  But right now, in the world, in the land of AWS and S3 outages, this is something that's foremost on a lot of people's minds.
[03:00.120 --> 03:04.520]  So, just a shot in the dark, does anybody like to throw out there, what is the cloud?
[03:04.520 --> 03:05.820]  Someone else's computer.
[03:07.080 --> 03:11.000]  Actually, very well done.
[03:13.240 --> 03:16.140]  When you talk to the vendors, they're going to come at you.
[03:16.160 --> 03:18.800]  This is a network. This is getting rid of your data center.
[03:18.800 --> 03:21.240]  This is your chance to export your costs.
[03:21.260 --> 03:23.980]  This is a chance to have other people helping with your infrastructure.
[03:24.040 --> 03:25.700]  It's going to minimize your downtime.
[03:25.980 --> 03:27.940]  Blah, blah, buzzword, buzzword.
[03:27.940 --> 03:30.860]  Are you distracted? Have you signed my statement of work yet?
[03:33.460 --> 03:38.160]  But, as my very astute member of the crowd mentioned, it's someone else's server.
[03:38.200 --> 03:43.580]  You boil it down, you're still doing all the stuff you're doing in your data center, or we're doing in your data center,
[03:43.580 --> 03:45.820]  but now somebody else is worried about the hardware.
[03:47.260 --> 03:52.320]  So, applying that to threat intelligence, let's try it out.
[03:52.320 --> 03:54.400]  What is threat intelligence?
[03:57.240 --> 03:58.740]  This is open to the crowd.
[04:00.720 --> 04:04.460]  All right, this is good, because it means you've actually come to hear me talk,
[04:04.460 --> 04:06.800]  and you're not just keeping the seat for the next presentation.
[04:08.380 --> 04:10.220]  All right, you're going to get your vendors.
[04:10.220 --> 04:12.760]  All right, this is crowdsourced. This is real-time.
[04:12.820 --> 04:15.100]  This is deep-thinking analytics.
[04:15.340 --> 04:19.040]  This is spread out across the world looking at all of our attack vendors.
[04:19.040 --> 04:21.740]  Blah, blah, blah. Ooh, that's a big check.
[04:23.540 --> 04:25.100]  It's someone else's log.
[04:25.200 --> 04:27.880]  In order for this to be actionable intelligence,
[04:27.880 --> 04:31.840]  it has had to have happened to someone somewhere first.
[04:32.680 --> 04:36.840]  So the basis when we look at threat intelligence is someone else's logs.
[04:41.140 --> 04:45.100]  So, where can I get this mythical threat intelligence?
[04:45.620 --> 04:47.640]  Number one, we have governments.
[04:48.300 --> 04:53.420]  Mostly our government, but some others actually share real threat intelligence from time to time.
[04:53.780 --> 04:58.520]  This is where we have things like the U.S. CERT, NIST sometimes,
[04:58.520 --> 05:01.500]  several other groups that, here, we're going to publish a vulnerability,
[05:01.500 --> 05:06.080]  or we're going to talk about something that has attacked critical infrastructure in the United States,
[05:06.080 --> 05:10.460]  and we're going to make it public so that you then have the chance to take this information,
[05:10.460 --> 05:13.640]  defend against it, or see if it's too late to defend against it
[05:13.640 --> 05:15.800]  and you need to remediate something that's happened.
[05:16.560 --> 05:17.760]  That are the vendors.
[05:18.220 --> 05:21.740]  If a vendor out there is not talking about threat intelligence,
[05:21.740 --> 05:26.220]  they're still probably breaking into the cloud space and trying to get you to buy their cloud offering.
[05:26.680 --> 05:30.180]  Everybody at this point has threat intelligence, whether it's a feed.
[05:30.180 --> 05:33.120]  We're going to give you our real-time information,
[05:33.120 --> 05:35.680]  and you're going to make a decision on what to do with that.
[05:35.680 --> 05:39.340]  Or, for a lot of the products now, it is baked in.
[05:39.340 --> 05:44.780]  They will talk about how it's analyzed from wherever across so many countries in your industry,
[05:44.780 --> 05:47.160]  and that is their baked-in threat intelligence.
[05:47.740 --> 05:50.380]  And then some of the more common ones are the sharing lists.
[05:50.580 --> 05:54.000]  For just about every industry there is out there,
[05:54.000 --> 05:59.240]  we have an ISAC list, Information Sharing and Analysis Center.
[05:59.480 --> 06:04.320]  And there, it's going to be other businesses and groups in your same industry,
[06:04.320 --> 06:08.840]  sharing their information, bouncing ideas off you, you bounce ideas off them,
[06:08.840 --> 06:10.380]  to come to a better understanding.
[06:10.380 --> 06:12.200]  And those lists are moderated.
[06:12.620 --> 06:15.480]  Then you have these sticks-and-taxi groups out there.
[06:15.480 --> 06:19.320]  Sticks-and-taxi being the protocols people are using to share threat intelligence
[06:19.320 --> 06:21.860]  if it's not coming through a list or a vendor.
[06:27.330 --> 06:30.310]  Now, when threat intelligence was really coming out,
[06:30.390 --> 06:34.350]  a gentleman by the name of Dave Bianco came up with the Pyramid of Pain.
[06:34.590 --> 06:37.650]  And his Pyramid of Pain works from the bottom of hash values
[06:37.650 --> 06:41.610]  up to the tools, techniques, and procedures at the top.
[06:41.890 --> 06:46.310]  And as you go up the pyramid, they go from everyday commodity,
[06:46.310 --> 06:48.090]  this will not matter in two minutes,
[06:48.090 --> 06:54.130]  to something that will help you repeatedly identify hackers of a specific group in your networks.
[07:00.150 --> 07:04.270]  Now, with all these vendors out there, we have all this threat intelligence,
[07:04.270 --> 07:07.750]  whether it's baked in, whether they're lists, whether it's feeds,
[07:08.290 --> 07:09.810]  what are they actually selling?
[07:09.870 --> 07:11.850]  It breaks down into three groups.
[07:11.850 --> 07:14.530]  We have the good, the bad, and the ugly.
[07:14.670 --> 07:18.750]  And yes, that is going to be a very bad movie reference for the next couple of slides.
[07:19.390 --> 07:23.810]  Starting at the top, the good is where these things are auto-updating in near real-time.
[07:23.910 --> 07:27.270]  They are crowdsourced, so they're looking across the industries that you are in
[07:27.270 --> 07:32.690]  to get real data of things that are actually happening in a recent time frame.
[07:33.130 --> 07:36.630]  And most importantly, and this should be highlighted, bolded,
[07:36.630 --> 07:39.770]  and if you're going to take anything away, write this down,
[07:39.770 --> 07:42.110]  it needs to be contextualized.
[07:42.110 --> 07:43.850]  Because when we get to the ugly,
[07:43.850 --> 07:49.130]  we are going to talk about how uncontextualized data can actually cause damage in your networks
[07:49.130 --> 07:53.350]  if the threat intelligence vendor is not doing their job right.
[07:53.350 --> 07:58.050]  And then the bad is just those bottom lines of the pyramid, where here's an indicator.
[07:58.490 --> 08:02.590]  This might be a fresh indicator, this might be an old indicator,
[08:02.590 --> 08:07.030]  but we're going to package it up so we can say that we're sending all this data out to you.
[08:11.080 --> 08:15.200]  So the good. The good will look at the top three steps of the pyramid,
[08:15.200 --> 08:20.020]  where we're looking at the artifacts on the machines, or artifacts on the network.
[08:20.100 --> 08:24.880]  When you're looking at your logs, do we see certain machines that are making these calls
[08:24.880 --> 08:27.360]  going to very similar URLs?
[08:27.360 --> 08:29.660]  Are there similar patterns in the URI stems?
[08:29.660 --> 08:36.040]  Something that would indicate the LAN attacker plans his setup, uses his algorithms.
[08:37.220 --> 08:39.240]  Okay, that's me. My bad.
[08:40.420 --> 08:42.220]  Are there changes in the host file?
[08:42.220 --> 08:44.280]  So when you look at the host file,
[08:44.280 --> 08:47.100]  there are some basic entries that have been overridden,
[08:47.100 --> 08:49.800]  so it can dodge most of your network defenses.
[08:49.800 --> 08:51.600]  Do you have a managed DNS?
[08:51.600 --> 08:55.160]  And is your DNS now routing out to a public DNS space?
[08:56.260 --> 08:57.700]  Then you have the tools.
[08:58.040 --> 08:59.820]  Are they using the same compression kits?
[08:59.820 --> 09:03.240]  Are they using what you natively have, your WinZips, your 7-Zips?
[09:03.240 --> 09:05.820]  Are they downloading WinRAR?
[09:06.080 --> 09:08.020]  What exploit kits are they using?
[09:08.040 --> 09:11.160]  Are they using the latest commoditized thing that you'll hear about?
[09:11.280 --> 09:14.180]  Is it the kits that are being sold as ransomware as a service?
[09:14.240 --> 09:15.980]  Or is it something they're homebrewing?
[09:15.980 --> 09:19.780]  Or is it something much older, like a forgotten-about black hole?
[09:20.340 --> 09:23.320]  And then, what shells are they using?
[09:23.320 --> 09:28.340]  Are they able to just simply bring up a command shell and do something within Windows?
[09:28.380 --> 09:31.620]  Are they using PowerShell, which is the new flavor of the day,
[09:31.620 --> 09:35.380]  because everybody has it, it's always turned on, it's very rarely restricted?
[09:35.500 --> 09:41.240]  Or are they dropping down, like in just a simple Netcat,
[09:41.240 --> 09:43.380]  because your defenses are not seeing it?
[09:43.720 --> 09:47.800]  And then the TTPs is how they take all the indicators you'll find,
[09:47.800 --> 09:51.760]  how they apply those in their specific order to get into your network,
[09:51.760 --> 09:55.280]  obscure that they're in your network, get the data out,
[09:55.280 --> 09:59.180]  and then clean up so you can't figure out how they did what they did.
[10:00.120 --> 10:02.020]  Now, it should be mentioned with all these,
[10:02.020 --> 10:05.620]  the number one thing to make this work is you need visibility in those networks.
[10:05.700 --> 10:09.720]  If you are not seeing any of this, or how they're doing any of this,
[10:09.720 --> 10:12.060]  threat intelligence will not do you much good.
[10:16.200 --> 10:17.800]  Not the bad.
[10:17.800 --> 10:20.620]  These are the most basic of indicators,
[10:20.620 --> 10:28.000]  because these things can be outmoded and irrelevant in moments to minutes
[10:28.000 --> 10:34.400]  to by the time you discover on the average of, I believe it's a year plus in the network.
[10:35.340 --> 10:38.180]  Here, what domains do they register?
[10:38.180 --> 10:40.280]  Are they going to keep using those domains?
[10:40.360 --> 10:44.480]  Generally speaking, repeatable domains are usually commoditized in Sol.
[10:44.480 --> 10:49.740]  So, yes, putting domains in a block list means you're going to stop the script kitties,
[10:49.740 --> 10:55.340]  who then found the same vulnerabilities the Chinese People's Third Army exploited five years ago.
[10:56.080 --> 10:59.100]  But arguably, most of that should be getting caught by your semantic,
[10:59.100 --> 11:03.740]  by your trend, your AVG, or any other anti-virus you're using.
[11:03.960 --> 11:06.020]  The same thing with the IP addresses.
[11:06.720 --> 11:09.840]  You can have an IP address as an indicator of compromise.
[11:10.000 --> 11:13.040]  You don't know if that server was originally hacked,
[11:13.040 --> 11:16.020]  if it was something staged at a hosting provider,
[11:16.020 --> 11:20.260]  if it's something that you may end up needing because it's a relevant source,
[11:20.260 --> 11:23.140]  like, say, Yahoo and their ad servers,
[11:23.560 --> 11:26.380]  that you may end up blocking when you need some of that data.
[11:26.440 --> 11:28.940]  More so than just the ads, obviously.
[11:29.120 --> 11:30.600]  And then the hash values.
[11:30.780 --> 11:34.240]  You've hashed out, this is a bad person that's attacking my network,
[11:34.240 --> 11:35.740]  and this is what we're going to share.
[11:35.880 --> 11:37.380]  Oh, they changed the variable.
[11:37.380 --> 11:42.340]  Your hash values are now as outdated as Hydrox cookies.
[11:45.860 --> 11:48.520]  Okay, I'm not the only old person in here. Outstanding.
[11:49.640 --> 11:52.740]  All right, now we get into the ugly.
[11:53.520 --> 11:57.760]  There are some vendors in the past who found that one indicator of compromise
[11:57.760 --> 12:02.420]  showed that the malware is repeatedly hitting on 127.0.0.1.
[12:02.500 --> 12:04.060]  No place like home.
[12:04.060 --> 12:07.940]  So tied into their system, if you see this indicator,
[12:07.940 --> 12:11.180]  you need to protect your network and get your host to block that.
[12:12.700 --> 12:16.300]  Oh my god, my entire enterprise team no longer get out to the internet
[12:25.180 --> 12:27.140]  or talk to each other.
[12:27.140 --> 12:28.460]  What happened?
[12:29.840 --> 12:33.900]  The sad thing is both of these are very true stories that have happened.
[12:34.140 --> 12:37.140]  The second one, what is a subdomain?
[12:37.500 --> 12:39.880]  Now, why img.com?
[12:39.880 --> 12:42.980]  This is Yahoo's content delivery network.
[12:43.260 --> 12:46.720]  Now, after the past six months, we can have an argument about
[12:46.720 --> 12:50.120]  whether or not blocking that whole subdomain is a bad thing.
[12:50.460 --> 12:52.520]  That's up to you and your policies.
[12:53.160 --> 12:57.760]  But in this situation, a bad guy created a subdomain.
[12:57.760 --> 13:00.580]  They were able to get in under the registrar, create a subdomain,
[13:00.580 --> 13:02.540]  get a DNS record set up for it.
[13:02.540 --> 13:07.780]  So now they were hosting all their badness at s.yimg.com.
[13:07.780 --> 13:11.580]  Now, one of the vendors with Threat Intelligence says,
[13:11.580 --> 13:12.480]  well, it's very simple.
[13:12.480 --> 13:16.600]  Maybe we didn't pay attention to what img.com is,
[13:16.600 --> 13:18.380]  but they might just spin up another subdomain.
[13:18.380 --> 13:20.360]  So we'll just block the whole thing.
[13:20.760 --> 13:26.100]  Now, a lot of us think of Yahoo as email, outdated, and very poor security.
[13:26.100 --> 13:28.820]  They also serve Yahoo finance pages,
[13:28.820 --> 13:31.760]  which are very widely used in the finance industry.
[13:31.880 --> 13:35.580]  More importantly, this happened in March.
[13:35.580 --> 13:39.320]  Imagine having to walk into a VP's office,
[13:39.320 --> 13:43.220]  because all of a sudden he can't fill out his March Madness bracket,
[13:43.220 --> 13:45.300]  because you have blocked it on the Internet.
[13:45.540 --> 13:48.980]  Where I come from, we refer to those as RGEs,
[13:48.980 --> 13:51.520]  or Resume Generating Events.
[13:52.020 --> 13:54.460]  Those you want to avoid actively.
[13:58.130 --> 14:01.270]  So, how do we take some of these bad indicators,
[14:01.270 --> 14:04.950]  which are very common, and make them actionable and good?
[14:05.470 --> 14:09.470]  In one scenario, a threat intelligence sharing list said,
[14:09.470 --> 14:12.870]  hey, we have somebody who's been hit by 25 IPs.
[14:12.870 --> 14:14.950]  These IPs have shown up as indicators.
[14:15.710 --> 14:17.830]  Has anybody else seen anything similar?
[14:18.870 --> 14:23.450]  Okay, well, as we discussed with IPs, that doesn't mean very much.
[14:23.450 --> 14:25.890]  We can trace them back, and maybe they are hosting companies
[14:25.890 --> 14:28.410]  in Amsterdam, or Russia, or Ukraine.
[14:28.470 --> 14:31.430]  Places that, if your policy allows,
[14:31.430 --> 14:34.910]  I would recommend blocking at the IP or domain level.
[14:35.450 --> 14:37.230]  Some of us are not that fortunate.
[14:39.410 --> 14:42.650]  So, we go into our SIEM, and this is where visibility kicks in.
[14:42.650 --> 14:44.010]  What do we see?
[14:45.250 --> 14:48.570]  Well, what I see first is the one typo in my presentation.
[14:49.130 --> 14:51.290]  1111 should be 5200 hits.
[14:51.290 --> 14:53.190]  This will be relevant on the next slide.
[14:53.990 --> 14:57.290]  And for the record, I'm sure many of you recognize some of these IPs.
[14:57.290 --> 15:00.030]  For obvious reasons, this has been somewhat sanitized.
[15:00.030 --> 15:01.950]  Please do not block these.
[15:01.950 --> 15:04.250]  You will find issues do abound.
[15:05.450 --> 15:09.370]  Now, what we see is, over different time frames,
[15:09.370 --> 15:12.930]  some of these IP attacks are far noisier than others.
[15:13.550 --> 15:15.850]  Are these random? Are these related?
[15:15.850 --> 15:19.750]  What we do see is, okay, one is far noisier than the rest.
[15:19.750 --> 15:21.670]  Another one is also very noisy.
[15:21.670 --> 15:25.410]  But things then taper off very dramatically after that,
[15:25.410 --> 15:28.050]  so you only see a small number of hits.
[15:32.160 --> 15:33.120]  Context.
[15:33.740 --> 15:37.220]  What we saw was, the big amount of noise was just
[15:37.220 --> 15:39.540]  port 80, port 443.
[15:39.540 --> 15:42.220]  What can I connect to in your IP space?
[15:42.600 --> 15:45.620]  And ironically, when it was discovered, it was even going after
[15:45.620 --> 15:48.520]  some IP space that was not attributed to
[15:48.520 --> 15:51.760]  the company in question that they in fact owned.
[15:52.800 --> 15:55.720]  Then, at the same time, we saw the port scans.
[15:55.840 --> 15:57.620]  Look, somebody is just bringing an Nmap scan
[15:57.620 --> 16:01.180]  against my infrastructure over and over and over again.
[16:01.180 --> 16:03.740]  What could they possibly figure out that they didn't see
[16:03.740 --> 16:06.720]  the first 200 times they scanned
[16:06.720 --> 16:08.000]  the IP space?
[16:08.680 --> 16:12.520]  Well, what we start seeing now, the idea was very simple.
[16:12.520 --> 16:14.960]  How much stuff can we stick in their logs
[16:14.960 --> 16:18.000]  to make it hard to find what we have?
[16:18.260 --> 16:20.340]  Fortunately, we have a little bit of
[16:21.000 --> 16:24.620]  log foo-grab-ability and a good sim that we can just,
[16:24.620 --> 16:27.880]  okay, I'm just going to strip out these IPs one by one and see what's left.
[16:28.220 --> 16:31.120]  Then, we see our web-facing servers are getting hit
[16:31.120 --> 16:33.100]  by shell-shock attacks.
[16:33.420 --> 16:34.840]  Okay, we patch those
[16:36.800 --> 16:39.480]  almost... I'm saying slightly after when Rango was president.
[16:39.640 --> 16:42.100]  Then we see other attacks where, okay,
[16:42.100 --> 16:45.320]  now they're going after things where they think they see an SSH port
[16:45.320 --> 16:48.220]  or a port that they might think parallels to SSH
[16:48.220 --> 16:51.280]  and they're going to start throwing SSH attacks at there.
[16:51.280 --> 16:53.940]  Can they brute force these? Can they get in?
[16:54.560 --> 16:56.740]  And then, most importantly, we then see
[16:56.740 --> 16:59.640]  four very specific FTP connection attempts.
[17:00.020 --> 17:03.320]  In those situations, though, we do not allow anonymous login.
[17:03.320 --> 17:06.260]  I am sorry, bad guy, but I applaud the attempt.
[17:06.620 --> 17:09.060]  What we later found out is for these other people
[17:09.060 --> 17:11.780]  who have seen more hits than what we had,
[17:11.780 --> 17:15.660]  as the additional hits came down, there were some more noisemakers in there,
[17:15.660 --> 17:17.820]  but then they explicitly went after
[17:17.820 --> 17:23.000]  make noise over here, do things that seem very alarming over here,
[17:23.000 --> 17:25.260]  and then take one poke at this.
[17:25.920 --> 17:27.600]  Maybe two pokes over there.
[17:28.160 --> 17:30.920]  Oh, look, we're able to get in here. Let's throw some more noise at it
[17:30.920 --> 17:33.680]  and do everything we can to obscure what we're doing.
[17:34.100 --> 17:37.280]  So what we see here, one, is a pattern of attack.
[17:37.460 --> 17:39.420]  Where are they making noise? How are they making noise?
[17:39.420 --> 17:41.360]  And then how are they trying to attack us?
[17:41.560 --> 17:43.960]  And then for those who actually saw them get in,
[17:43.960 --> 17:46.680]  all right, now we have actionable intelligence to share.
[17:46.780 --> 17:50.420]  This is what they're doing. This is how they're trying to do it.
[17:50.480 --> 17:54.320]  So if you start to see these patterns, go ahead and skip to the bottom of the list.
[17:54.320 --> 17:56.040]  Because if you start working your way up from the bottom,
[17:56.040 --> 17:58.820]  if you see these IPs, you are really in trouble.
[17:58.820 --> 18:01.680]  But this is explicitly what you need to look for,
[18:01.680 --> 18:03.980]  because this is how they would have gotten your data.
[18:04.120 --> 18:06.500]  And if they got that far, this is how they got it out.
[18:06.820 --> 18:10.620]  And if you still don't see that, Burger King's hired.
[18:15.080 --> 18:17.380]  So, would you like to know more?
[18:18.400 --> 18:21.100]  In this situation, as mentioned previously,
[18:21.100 --> 18:23.960]  yes, well, I'm still not the oldest person here.
[18:24.640 --> 18:30.040]  All right, number one, look for an information sharing and analysis center list in your industry.
[18:30.160 --> 18:34.960]  Like I said, they exist across every major broad category that's out there.
[18:34.960 --> 18:36.980]  You're in real estate, they got a list.
[18:36.980 --> 18:39.860]  You're in manufacturing, they got a list.
[18:39.860 --> 18:45.340]  You're in financial services, retail, hospitality, they all have lists.
[18:45.480 --> 18:49.340]  And all they really ask you to do is to be able to share information back.
[18:49.620 --> 18:52.300]  You will join this, it will authenticate that you're in that industry.
[18:52.300 --> 18:55.880]  And then, all right, here's the information we're going to give you.
[18:55.880 --> 18:58.500]  Please share back or respond when we have discussions,
[18:58.500 --> 19:02.820]  so we can all contribute and make it a better internet for everybody else.
[19:02.820 --> 19:04.740]  Rainbows, unicorns, and Care Bears.
[19:05.220 --> 19:07.540]  Number two is your vendor offerings.
[19:07.540 --> 19:11.340]  Especially if you're just getting started, you're dipping your pinky toe in,
[19:11.340 --> 19:13.820]  this is where you look at what the vendors can get you.
[19:13.820 --> 19:16.420]  Because in most cases, vendors...
[19:16.420 --> 19:19.540]  I'm trying to say vendor agnostic here, I'm just going to leave it at vendors...
[19:20.700 --> 19:25.800]  have offerings where your data will come in, come through, pass through one of their signatures,
[19:25.800 --> 19:30.280]  signature readers, pass pet, one of their devices on the endpoints of the network,
[19:30.280 --> 19:32.980]  maybe get read by an agent on your host.
[19:32.980 --> 19:37.080]  And they will compare it in their cloud to, well, we have all these clients around the world.
[19:37.080 --> 19:42.640]  What else do we see from them that is real-time, that is happening right now,
[19:42.640 --> 19:47.780]  that based on what industry you're in, may be a relevant indicator to you.
[19:48.100 --> 19:51.340]  And in those cases, there's usually an automated response.
[19:52.380 --> 19:57.020]  Trying to stay away from vendors, there's a firewall vendor somewhere out in California there
[19:57.020 --> 20:01.580]  that has a product that when your stuff gets scanned, it crosses your boundary.
[20:01.580 --> 20:05.960]  And it checks against their cloud, and within five minutes, I believe it is,
[20:05.960 --> 20:09.580]  it will come back, hey, that's something new we haven't seen,
[20:09.580 --> 20:12.200]  or we've seen it in one or two places, and that's really bad.
[20:12.200 --> 20:13.780]  You should do something about that.
[20:13.920 --> 20:17.320]  Or in several cases, we've seen this in quite a number of places,
[20:17.320 --> 20:20.120]  so we're blocking it immediately and it doesn't come in.
[20:20.580 --> 20:25.380]  That threat intelligence is relatively invisible, but it is still threat intelligence,
[20:25.380 --> 20:27.640]  and once again, a very good place to start.
[20:28.000 --> 20:31.800]  Especially if your organization does not have money for dedicated teams
[20:31.800 --> 20:37.060]  or amazingly charismatic, beautiful, well-dressed people like myself.
[20:38.060 --> 20:40.280]  I appreciate your troubles on that one.
[20:42.900 --> 20:46.500]  So, to paraphrase Ronald Reagan,
[20:46.500 --> 20:49.800]  does anybody have any questions before I run for the door?
[20:53.700 --> 20:55.720]  All right, ladies and gentlemen, thank you.