WEBVTT 0:00:02.100000 --> 0:00:09.160000 This video is titled Combating Web-based Threats using Cisco WSA and CWS. 0:00:09.160000 --> 0:00:11.900000 In this video, the main things I'm going to cover is I'm going to do an 0:00:11.900000 --> 0:00:14.060000 introduction to web-based threats. 0:00:14.060000 --> 0:00:15.820000 What is a web-based threat? 0:00:15.820000 --> 0:00:18.280000 What are the common ones you might see? 0:00:18.280000 --> 0:00:23.080000 We're going to contrast cloud-based versus local web proxies. 0:00:23.080000 --> 0:00:26.720000 I'm going to introduce you to a couple of Cisco platforms designed to 0:00:26.720000 --> 0:00:32.500000 combat web-based threats, namely the Cisco WSA and CWS service. 0:00:32.500000 --> 0:00:36.640000 They're going to look at the traffic flow in order to make the WSA and 0:00:36.640000 --> 0:00:42.460000 or CWS actually useful in combating web-based threats. 0:00:42.460000 --> 0:00:52.300000 Okay, so when we say a web-based threat, what are we talking about? 0:00:52.300000 --> 0:00:54.060000 Well, there are several. 0:00:54.060000 --> 0:00:58.300000 There's four main ones we're going to point out right here. 0:00:58.300000 --> 0:01:03.500000 So definitely request for websites to break an acceptable use policy. 0:01:03.500000 --> 0:01:06.360000 Probably not something you would find at home with your home user, but 0:01:06.360000 --> 0:01:09.560000 certainly if you're working for a company, they might have an acceptable 0:01:09.560000 --> 0:01:13.200000 use policy that says, if you're going to use our network, there are certain 0:01:13.200000 --> 0:01:16.220000 websites that you agree not to visit. 0:01:16.220000 --> 0:01:20.540000 You agree not to use our network to visit pornographic websites, violent 0:01:20.540000 --> 0:01:25.020000 websites. Websites designed to help you cheat and steal. 0:01:25.020000 --> 0:01:28.400000 So we want some sort of mechanism to prevent people from going to those 0:01:28.400000 --> 0:01:34.160000 websites because after all, they agreed that they would adhere to that. 0:01:34.160000 --> 0:01:37.620000 We want to prevent people from going to known malicious websites that 0:01:37.620000 --> 0:01:40.740000 install malware, spyware, or viruses. 0:01:40.740000 --> 0:01:43.880000 A lot of websites out there that people go to for like file sharing and 0:01:43.880000 --> 0:01:46.760000 downloading of music or videos are well known. 0:01:46.760000 --> 0:01:50.620000 Those websites also will get you with malware or viruses. 0:01:50.620000 --> 0:01:53.220000 We want to prevent people from even getting to those websites in the first 0:01:53.220000 --> 0:01:56.780000 place. What about legitimate websites? 0:01:56.780000 --> 0:01:59.420000 Sometimes legitimate websites are compromised. 0:01:59.420000 --> 0:02:02.820000 Sometimes people manage to hack into a legitimate website and install 0:02:02.820000 --> 0:02:07.020000 a link or something you can click on that would download malware or viruses 0:02:07.020000 --> 0:02:07.860000 to your computer. 0:02:07.860000 --> 0:02:11.460000 So we want to be able to protect against that as well. 0:02:11.460000 --> 0:02:14.660000 And also employees contributing to corporate data loss through unauthorized 0:02:14.660000 --> 0:02:17.540000 slash unmonitored data uploads. 0:02:17.540000 --> 0:02:21.700000 Maybe your company has a policy that says you were not to use Dropbox. 0:02:21.700000 --> 0:02:25.440000 Dropbox is out of our control, Google Drive is out of our control, all 0:02:25.440000 --> 0:02:27.840000 of our files should stay locally right here. 0:02:27.840000 --> 0:02:30.260000 Those are two websites you should not go to. 0:02:30.260000 --> 0:02:33.980000 So we want some sort of actionable plan to prevent people from going to 0:02:33.980000 --> 0:02:38.500000 websites like that and potentially uploading information that could really 0:02:38.500000 --> 0:02:41.460000 seriously hurt our company. 0:02:41.460000 --> 0:02:45.500000 So Cisco has two main solutions for this, at least at the CCNA security 0:02:45.500000 --> 0:02:49.080000 level. If you're studying for that, the two main solutions they want you 0:02:49.080000 --> 0:02:56.200000 to know about are Cisco's cloud web security and the web security appliance 0:02:56.200000 --> 0:03:00.540000 that also utilizes integrated AMP technology. 0:03:00.540000 --> 0:03:05.000000 So in both of these scenarios, what we're really talking about is implementing 0:03:05.000000 --> 0:03:07.540000 something called a web proxy. 0:03:07.540000 --> 0:03:09.480000 So what is a web proxy? 0:03:09.480000 --> 0:03:10.880000 Let's just start with that. 0:03:10.880000 --> 0:03:19.360000 So normally on your laptop, when you initiate a request for a website, 0:03:19.360000 --> 0:03:24.860000 your laptop creates its HTTP or HTTPS request and sends that packet directly 0:03:24.860000 --> 0:03:28.280000 to wherever the IP address is of the website. 0:03:28.280000 --> 0:03:32.300000 So a proxy simply means that there's some device in the middle to where 0:03:32.300000 --> 0:03:36.040000 that of either your laptop is configured that when it sends a request 0:03:36.040000 --> 0:03:40.960000 for a website, it first goes to that device, that device intercepts it 0:03:40.960000 --> 0:03:45.580000 and then forwards it on, or maybe it's all behind the scenes. 0:03:45.580000 --> 0:03:49.440000 Maybe your laptop has no idea that that device actually exists. 0:03:49.440000 --> 0:03:53.920000 Your laptop learns what the IP address is of the destination website, 0:03:53.920000 --> 0:04:00.080000 creates the HTTP or HTTPS packet, sends along its way, but before it leaves 0:04:00.080000 --> 0:04:05.220000 your company's network, it hits some networking device, commonly a firewall, 0:04:05.220000 --> 0:04:08.060000 that says, oh, this is outbound HTTP. 0:04:08.060000 --> 0:04:10.140000 This is outbound HTTPS. 0:04:10.140000 --> 0:04:14.180000 I need to redirect that to an internal device here known as a web proxy, 0:04:14.180000 --> 0:04:18.380000 so that web proxy can intercept it and inspect it. 0:04:18.380000 --> 0:04:22.460000 Another common characteristic of a web proxy is that once it has intercepted 0:04:22.460000 --> 0:04:28.140000 your web request, the proxy on your behalf will initiate the connection 0:04:28.140000 --> 0:04:30.440000 to the web server. 0:04:30.440000 --> 0:04:35.860000 Now to you, the local client, all this is transparent and invisible behind 0:04:35.860000 --> 0:04:41.240000 the scenes, you don't even know this is going on. 0:04:41.240000 --> 0:04:45.060000 So what's kind of interesting here is that if you read a Cisco's documentation 0:04:45.060000 --> 0:04:51.940000 things, in this particular case, usually SAS stands for software as a 0:04:51.940000 --> 0:04:56.360000 solution. In this case, we're talking about security as a service. 0:04:56.360000 --> 0:05:01.280000 Instead of software as a service, we've got security as a service. 0:05:01.280000 --> 0:05:06.920000 So if you use a cloud-based proxy, well, number one, that means you don't 0:05:06.920000 --> 0:05:09.540000 need to buy any special hardware software. 0:05:09.540000 --> 0:05:14.420000 There's nothing you have to purchase and install and maintain in your 0:05:14.420000 --> 0:05:16.120000 own company headquarters. 0:05:16.120000 --> 0:05:20.520000 So it negates the need for hardware maintenance or software upgrades. 0:05:20.520000 --> 0:05:25.400000 It can be accessed by corporate users, mobile users, and home teleworkers 0:05:25.400000 --> 0:05:28.040000 by using something called software connectors. 0:05:28.040000 --> 0:05:31.280000 We'll talk about that in a later video. 0:05:31.280000 --> 0:05:35.840000 Cisco's solution for this is Cisco Cloud Web Security. 0:05:35.840000 --> 0:05:40.100000 So with Cloud Web Security, basically you are, when you create your web 0:05:40.100000 --> 0:05:43.400000 request, whether you're sitting in the office, it's mostly designed for 0:05:43.400000 --> 0:05:46.820000 people sitting in the office, but even mobile workers could do this too. 0:05:46.820000 --> 0:05:51.340000 But let's just say you're sitting in the office and you, on your browser, 0:05:51.340000 --> 0:05:55.560000 you browse INE.com or CNN.com or something like that. 0:05:55.560000 --> 0:05:59.820000 Well, instead of your web request going directly there, your web request 0:05:59.820000 --> 0:06:04.940000 will be redirected to a Cisco device sitting in the cloud, which would 0:06:04.940000 --> 0:06:06.320000 get your request. 0:06:06.320000 --> 0:06:10.300000 That device would make sure it meets acceptable use policy, corporate 0:06:10.300000 --> 0:06:14.200000 policy. If all that stuff is good, then it will initiate a connection 0:06:14.200000 --> 0:06:17.360000 on your behalf to that remote web server. 0:06:17.360000 --> 0:06:19.720000 And then when the remote red server responds back, it doesn't respond 0:06:19.720000 --> 0:06:20.980000 back directly to you. 0:06:20.980000 --> 0:06:24.900000 It responds back to the Cisco device sitting in the cloud that's running 0:06:24.900000 --> 0:06:26.460000 Cloud Web Security. 0:06:26.460000 --> 0:06:30.660000 So it can see the web traffic that's coming back in reply, scrub it, make 0:06:30.660000 --> 0:06:36.660000 sure it's safe. If it is, it can then send it back to you. 0:06:36.660000 --> 0:06:42.020000 Now, the downside to this is that, number one, you're not in control of 0:06:42.020000 --> 0:06:44.980000 the actual device that's doing the web proxying. 0:06:44.980000 --> 0:06:46.380000 It's in the cloud. 0:06:46.380000 --> 0:06:50.000000 It is owned, operated, and maintained by Cisco. 0:06:50.000000 --> 0:06:53.700000 Now, your network administrator can get to it remotely. 0:06:53.700000 --> 0:06:57.360000 There's a GUI the network administrator can bring up to get to that device 0:06:57.360000 --> 0:07:02.460000 to configure it so that when it receives traffic from your organization, 0:07:02.460000 --> 0:07:05.920000 that traffic can be inspected and monitored based on your organization's 0:07:05.920000 --> 0:07:09.020000 policies. But you can't actually get to the device itself. 0:07:09.020000 --> 0:07:10.340000 You can't feel it touch it. 0:07:10.340000 --> 0:07:13.420000 Who knows where it is physically actually residing. 0:07:13.420000 --> 0:07:18.660000 Now, that might make some people nervous because if it goes down, there's 0:07:18.660000 --> 0:07:19.800000 no way you can bring it up. 0:07:19.800000 --> 0:07:22.620000 You'll have to rely on whoever's in the data center of wherever that cloud 0:07:22.620000 --> 0:07:25.100000 is to troubleshoot that and bring it up. 0:07:25.100000 --> 0:07:28.320000 You have to hope that they'll have enough resources to put on that if 0:07:28.320000 --> 0:07:29.700000 something goes wrong. 0:07:29.700000 --> 0:07:34.940000 Or sometimes you might be an organization like a federal or a governmental 0:07:34.940000 --> 0:07:38.800000 organization or something that's highly secretive that deals with top 0:07:38.800000 --> 0:07:43.240000 secret information and just the nature of your corporation and maybe the 0:07:43.240000 --> 0:07:48.960000 nature of the customers you're dealing with and it forces you to have 0:07:48.960000 --> 0:07:52.720000 something on premises that you do control and manage that's on your inside 0:07:52.720000 --> 0:07:54.740000 network of your firewall. 0:07:54.740000 --> 0:07:58.160000 In that case, you're going to want to have an on premises solution as 0:07:58.160000 --> 0:08:02.140000 either a real physical appliance, a box that you can screw into a rack 0:08:02.140000 --> 0:08:06.460000 somewhere, or a virtual appliance, which is going to be installed as software 0:08:06.460000 --> 0:08:10.580000 in a server that you own and control. 0:08:10.580000 --> 0:08:14.740000 So the benefits of this is anonymity is preserved. 0:08:14.740000 --> 0:08:19.460000 You see, if we're using Cisco's Cloud Web Security solution, then that 0:08:19.460000 --> 0:08:24.680000 means that their server, which they control, they monitor, is seeing all 0:08:24.680000 --> 0:08:27.520000 the stuff our company is sending to the Internet. 0:08:27.520000 --> 0:08:31.360000 So any web look up that our company is sending, any browsing that we're 0:08:31.360000 --> 0:08:34.000000 doing is being inspected by that device. 0:08:34.000000 --> 0:08:37.240000 And remember, that device in the cloud is out of our control. 0:08:37.240000 --> 0:08:41.120000 Who knows who has access to it out there and is able to monitor and sniff 0:08:41.120000 --> 0:08:43.500000 whatever websites we're looking up. 0:08:43.500000 --> 0:08:48.100000 Whereas if we have an on premises solution, anonymity is preserved. 0:08:48.100000 --> 0:08:51.660000 Only the person who's monitoring that device who presumably works for 0:08:51.660000 --> 0:08:55.460000 our company as an internal employee could see these various websites that 0:08:55.460000 --> 0:08:59.180000 we're looking up and what data we're getting back. 0:08:59.180000 --> 0:09:02.200000 You have complete control over your solution. 0:09:02.200000 --> 0:09:07.640000 Gives you much finer granularity over reporting and statistics than a 0:09:07.640000 --> 0:09:08.460000 cloud web solution. 0:09:08.460000 --> 0:09:12.200000 So Cisco's solution for this is purchasing an appliance called the Cisco 0:09:12.200000 --> 0:09:14.860000 Web Security Appliance. 0:09:14.860000 --> 0:09:16.080000 So let's introduce that. 0:09:16.080000 --> 0:09:17.800000 Let's talk about the Cisco WSA. 0:09:17.800000 --> 0:09:21.940000 There is what it looks like as an actual physical appliance that you would 0:09:21.940000 --> 0:09:28.180000 plug into Iraq. So WSA stands for Web Security Appliance. 0:09:28.180000 --> 0:09:32.220000 This is a Web proxy device that's local to your organization. 0:09:32.220000 --> 0:09:36.360000 Monitors and controls outbound web requests for web content and scrubs 0:09:36.360000 --> 0:09:42.360000 the return traffic for unwanted or malicious content. 0:09:42.360000 --> 0:09:46.660000 So all the web traffic from the clients, your laptops, your PCs, your 0:09:46.660000 --> 0:09:50.360000 servers, even your mobile tablets and smartphones in your organization 0:09:50.360000 --> 0:09:54.820000 have to somehow be redirected to this thing before they're allowed outside 0:09:54.820000 --> 0:09:57.560000 the firewall to the actual destination website. 0:09:57.560000 --> 0:10:03.260000 So remember as a proxy device, it's going to intercept all web requests, 0:10:03.260000 --> 0:10:08.400000 make sure those web requests meet your acceptable use policy, and then 0:10:08.400000 --> 0:10:13.220000 initiate on your behalf web connections to those remote servers. 0:10:13.220000 --> 0:10:18.660000 So the question then becomes how do we get our web requests like when 0:10:18.660000 --> 0:10:29.500000 I bring up my laptop or notebook or whatever, you know, fastcars.com or 0:10:29.500000 --> 0:10:32.980000 whatever it happens to be, how do we ensure that that request gets to 0:10:32.980000 --> 0:10:37.140000 this box as opposed to just going right outside the network to the actual 0:10:37.140000 --> 0:10:38.620000 destination website? 0:10:38.620000 --> 0:10:40.620000 Well, there's one of two ways we could do it. 0:10:40.620000 --> 0:10:44.280000 We could actually manually configure the actual end user laptop servers 0:10:44.280000 --> 0:10:49.560000 and PCs, like it says here explicit proxy configuration on clients. 0:10:49.560000 --> 0:10:53.700000 So kind of tedious to do that, but that is certainly an option that you 0:10:53.700000 --> 0:11:00.420000 could have. Or we could use the web cache control protocol WCCP to redirect 0:11:00.420000 --> 0:11:03.260000 traffic from network devices to this device. 0:11:03.260000 --> 0:11:07.400000 This is a much more popular method because it doesn't involve hands-on 0:11:07.400000 --> 0:11:10.220000 on the laptops or PCs at all. 0:11:10.220000 --> 0:11:14.420000 The laptops or PCs can create the request, they can send it to the destination, 0:11:14.420000 --> 0:11:17.500000 but before it gets the destination, it's going to hit like a firewall 0:11:17.500000 --> 0:11:20.940000 most likely within our organization that will recognize that as being 0:11:20.940000 --> 0:11:27.760000 web browsing traffic and then using WCCP redirect it to the web security 0:11:27.760000 --> 0:11:33.300000 appliance. We could also use policy -based routing or other methods if 0:11:33.300000 --> 0:11:38.060000 we have networking devices that don't support WCCP. 0:11:38.060000 --> 0:11:40.800000 So here's the traffic flow that we're looking at. 0:11:40.800000 --> 0:11:49.220000 So this is outbound traffic flow using a WSA that is in your campus itself. 0:11:49.220000 --> 0:11:52.620000 So the steps that we see here is number one. 0:11:52.620000 --> 0:11:55.300000 This guy here creates his web look up. 0:11:55.300000 --> 0:12:01.780000 So now he's sending an HTTP get message or an HTTP request for iany.com, 0:12:01.780000 --> 0:12:03.240000 Google.com, whatever it is. 0:12:03.240000 --> 0:12:04.880000 So there it is, it's going out. 0:12:04.880000 --> 0:12:09.800000 But before it leaves the network, it gets intercepted by some device. 0:12:09.800000 --> 0:12:11.380000 In this case, it's a firewall. 0:12:11.380000 --> 0:12:13.260000 We could also use a router to intercept that. 0:12:13.260000 --> 0:12:17.220000 And the idea is whatever that device is recognizes that is outbound web 0:12:17.220000 --> 0:12:19.160000 traffic and redirects it. 0:12:19.160000 --> 0:12:20.740000 That's step number two here. 0:12:20.740000 --> 0:12:23.300000 Redirects it to our WSA. 0:12:23.300000 --> 0:12:26.820000 Our WSA then has a chance to inspect that traffic. 0:12:26.820000 --> 0:12:31.540000 If the traffic is bad, that's step number three. 0:12:31.540000 --> 0:12:34.440000 Now it's send a little message back which shows up as a web page saying 0:12:34.440000 --> 0:12:37.080000 the page you're trying to access is denied. 0:12:37.080000 --> 0:12:40.100000 Or you could have a web page that you build itself saying, I'm sorry, 0:12:40.100000 --> 0:12:42.500000 but you're breaking our acceptable use policy. 0:12:42.500000 --> 0:12:44.280000 You are about to lose your job. 0:12:44.280000 --> 0:12:45.660000 Thank you very much. 0:12:45.660000 --> 0:12:49.400000 But number three here is a message saying, sorry, couldn't process your 0:12:49.400000 --> 0:12:52.040000 request. You're trying to get to a website that we don't allow. 0:12:52.040000 --> 0:12:56.800000 But if the WSA says, hey, that website's okay, then that's number four. 0:12:56.800000 --> 0:13:02.640000 The WSA will initiate a web look up on your behalf. 0:13:02.640000 --> 0:13:07.880000 You'll get the response back from the website. 0:13:07.880000 --> 0:13:09.560000 And then the WSA will scrub it. 0:13:09.560000 --> 0:13:11.380000 He'll make sure, okay, is this all right? 0:13:11.380000 --> 0:13:12.820000 Is there anything malicious here? 0:13:12.820000 --> 0:13:15.160000 If the answer is yes, that's it. 0:13:15.160000 --> 0:13:16.560000 You're done. You're back to step. 0:13:16.560000 --> 0:13:20.100000 And you're now step number six could be same thing as step number three. 0:13:20.100000 --> 0:13:22.940000 Step number six could be a message saying, I'm sorry, but this web page 0:13:22.940000 --> 0:13:24.320000 could not be displayed. 0:13:24.320000 --> 0:13:27.740000 It contains malicious or unwanted traffic or something like that. 0:13:27.740000 --> 0:13:30.860000 Or it could be the website is perfectly fine. 0:13:30.860000 --> 0:13:34.740000 In which case step number six here would be actually delivering you the 0:13:34.740000 --> 0:13:46.000000 content of that website you wanted to see. 0:13:46.000000 --> 0:13:49.960000 Now, as far as a cloud web solutions concerned, this is where you might 0:13:49.960000 --> 0:13:53.020000 want to use Cisco's cloud web security. 0:13:53.020000 --> 0:13:58.960000 It's a cloud proxy, very similar in functionality to the WSA. 0:13:58.960000 --> 0:14:04.280000 And you as a network administrator, you can log into this thing via a 0:14:04.280000 --> 0:14:08.780000 GUI, and it gives you usage controls with category and reputation based 0:14:08.780000 --> 0:14:12.580000 controls, malware filtering, data protection, all kinds of good stuff. 0:14:12.580000 --> 0:14:16.900000 By the way, this device, the solution, formerly went by different name. 0:14:16.900000 --> 0:14:18.760000 It was called ScanSafe. 0:14:18.760000 --> 0:14:22.800000 So if you ever see any documents or anything about ScanSafe, that's now 0:14:22.800000 --> 0:14:25.240000 what's known as cloud web security. 0:14:25.240000 --> 0:14:28.120000 So where's this reside all over the place? 0:14:28.120000 --> 0:14:30.360000 Spread geographically all over the world. 0:14:30.360000 --> 0:14:32.680000 They're interconnected and redundant. 0:14:32.680000 --> 0:14:37.660000 And even on mobile devices like smartphones and laptops are mobile. 0:14:37.660000 --> 0:14:41.500000 If you install the Cisco AnyConnect Secure Mobility Client, special piece 0:14:41.500000 --> 0:14:46.940000 of software under those devices, you can configure any connect to cloud 0:14:46.940000 --> 0:14:52.000000 web security. And so the idea behind this is basically the same thing 0:14:52.000000 --> 0:14:57.520000 except now, instead of having your proxy local to yourself, it is located 0:14:57.520000 --> 0:15:01.600000 in the cloud. So step number one, the user browses to a website. 0:15:01.600000 --> 0:15:05.360000 Step number two, that gets to a firewall or router. 0:15:05.360000 --> 0:15:08.700000 The router recognizes that as an outbound web request. 0:15:08.700000 --> 0:15:14.300000 In this case, instead of redirecting it to a local web security appliance 0:15:14.300000 --> 0:15:17.320000 in your own company, instead of redirecting it across the internet, across 0:15:17.320000 --> 0:15:22.600000 the cloud, to one of the cloud website web security data centers. 0:15:22.600000 --> 0:15:26.560000 And then there, they look at your outbound request to see, is it meeting 0:15:26.560000 --> 0:15:28.240000 the acceptable use policy? 0:15:28.240000 --> 0:15:30.260000 Is it going to an unauthorized website? 0:15:30.260000 --> 0:15:36.620000 Is there anything that would prevent this website from being blocked? 0:15:36.620000 --> 0:15:39.860000 Now it could choose to block it, could choose to block the content, the 0:15:39.860000 --> 0:15:44.320000 file or the URL, or it could choose to just forward your request on to 0:15:44.320000 --> 0:15:46.960000 the actual website itself. 0:15:46.960000 --> 0:15:52.820000 And in the reverse direction, we see the website response. 0:15:52.820000 --> 0:15:56.080000 That response goes back to cloud web security because remember, cloud 0:15:56.080000 --> 0:16:00.280000 web security is a proxy, it acted on your behalf. 0:16:00.280000 --> 0:16:03.780000 So it initiated a connection to the website. 0:16:03.780000 --> 0:16:07.680000 The website has no visibility into you as the end user, has no idea that 0:16:07.680000 --> 0:16:10.680000 you exist or you even want to browse it. 0:16:10.680000 --> 0:16:14.760000 So the connection looks like it's coming from cloud web security. 0:16:14.760000 --> 0:16:19.260000 Now the cloud web security gets that web page back once again, it scans 0:16:19.260000 --> 0:16:21.220000 it. Is there anything malicious here? 0:16:21.220000 --> 0:16:23.080000 Anything against corporate use policy? 0:16:23.080000 --> 0:16:27.520000 If the answer is no, this website is perfectly fine, then it forwards 0:16:27.520000 --> 0:16:29.520000 it on back to you. 0:16:29.520000 --> 0:16:34.800000 So that concludes this introduction to web-based security threats and 0:16:34.800000 --> 0:16:38.560000 some high level ways you could protect against that with Cisco's cloud 0:16:38.560000 --> 0:16:42.120000 web security or Cisco's web security appliance.