Network Security Fundamentals

0:00[MUSIC PLAYING] Hello and welcome. My name is Keith Barker. And this set of videos, you and I. Get to discuss network security fundamentals, including the devices and components and ideas. That we should integrate at the beginning as part of our network overall designs to increase security. And a very prominent figure in the posture of security on networks today. Is a device called a firewall. So we'll continue our discussion in the next video.

0:31We will focus on the various types of firewalls. Their names and what some do and don't do. That can be critical to our security. So I'll see you, my friend, in the very next video.

0:00[AUDIO LOGO] In this video, you and I get to chat about firewalls, including some types and categories, and features that we really ought to be looking for when considering protecting our networks. And as we focus our attention here on firewalls, let me also just point out that a firewall doesn't always mean a network device. There's also the concept of a firewall that could be running on a server or on a computer.

0:30And that would be a software based firewall, that can protect and allow certain things to happen or not to happen. For example, a firewall in software running on this server, could prevent certain types of traffic from entering into the server. Or firewall software running on the server could prevent certain types or certain applications from running. However, for this video, specifically, I'd like to focus on network devices acting as firewalls. And here's a beautiful image of one right here. And when you think of a firewall, a network device that's acting as a firewall, think of something that's offering resistance.

1:03That's trying to stop something from happening. Maybe it's stopping certain traffic from going over here to over there, and part of that might be only allowing certain types of traffic through the firewall. And one of the earliest methods for controlling traffic through the network at a firewall, was to use a technique called packet filtering. And when you think of packet filtering, which can be done today on firewall interfaces and router interfaces-- and when I think of packet filtering, I think of a bodyguard. Let's say there's a establishment a building and there's a door right here, and then we have a bodyguard or a bouncer, I guess would be a better analogy.

1:38A bouncer who's standing by the door, and is looking at every who's trying to come in or out of that door. So maybe the bodyguard has been given a list saying, hey, people with orange hats aren't allowed in or out. So basically check everybody's hats and if you had an orange hat, it would not allow you in or out of the building. And with packet filtering, it was normally looking at layer 3 information like IP addresses, and/or layer 4 information, which could include things such as the actual protocol on used TCP or UDP and/or the ports involved. So if we had a server that was reachable or the public internet, here at the firewall we get a rule that says, OK, allow traffic if it's going to the IP address associated with this server, and if it's destined for TCP port 443, which is the well-known port for HTTPS.

2:23That's an example-- if we did it based on this port, that would be an example of packet filtering on a network security device. So if something on the outside try to come into a different port like TCP port 80, or some other port other than 443, the packet filtering rule could say, nope, not allowed. And packet filtering has been around for decades and decades, but it's not great all by itself. For example, let's imagine you have a user right here and let's call this user 1. And that user is going out to the internet.

2:54Now, what types of applications and services are they using? Are they using DNS? Yes they are. Are they using HTTPS? Yes, behind the scenes with TLS very likely. And with these application layer services, the client computer is using some high-numbered port. Let's say it's a 6784, for the UDP port with the DNS request. And maybe for HTTPS uses 6798, as the source port for the TCP used. And that would be at layer 4. And then, it'd be destined to the well-known port for the DNS service, which is 53, and for HTTPS it would be TCP port 443.

3:30So with packet filtering, I guess we could set up a packet filter some rules and said, please, allow traffic destined to UDP port 53. And destined to TCP port 443 to support these applications, and the traffic might be able to go out but what about the reply traffic coming back in? So when the replies come back in, the destination ports are going to be 6874 and 6797 respectively. And if we have an access control list that's trying to control all that, how do we know what those ports are even going to be?

4:00So packet filtering is a function, however, it's not very efficient for the real traffic that we have going through our networks today. So here's what most organizations are going to do. They're going to take the networks that they trust the most. For example, their internal networks, and the firewalls that are connected to those internal networks, and they're going to associate those into what's known as a zone. So I'm going to call this the inside zone, which represents these networks, which I fairly trust. And I say fairly trust because we don't want to completely trust any networks, whether they're internal to our company or outside.

4:34However, from a comparison perspective, we might want to take the networks that we don't manage, for example, the internet, and associate all of those with the interfaces on our firewall to face those networks, and put that in a separate zone. For example, we could call that the outside zone. And with those zones in place, we could then set up policy to say, please, allow traffic that if it's initiated from devices and networks that are associate to the inside zone, and is trying to be routed out to the outside zone, please, allow that initial flow of traffic.

5:06So that users like user 1, can make DNS requests or HTTPS requests and go out to the internet. Now, the challenge is, what about traffic trying to come back from the outside zone, and being routed back to the inside? By default, our firewall is going to have a policy that says, any traffic that started that was initiated by a user out here on the outside that's trying to come to the inside, we're just going to go ahead and say no to that. Do not allow that traffic in. But at the same time, what about user 1, who's trying to get a response back in?

5:37And that's where we come into our next type of firewall, and it's called a stateful firewall. So only the word stateful, and I've also seen it listed as stateful filtering or stateful inspection. All those are great, but the major concept here's stateful, and here's how it works. When the user's traffic goes out because it's permitted-- the initial flow goes out from the inside to the outside-- the firewall is going to memorize and remember the state of that session. It'll know the ports involved, the source IP addresses, where it was going to.

6:10And if there's a response that comes back, that's exactly perfect based on what that client requested. Meaning, it's going back to that user, is going to the correct ports. The firewall because of the stateful table and remembering that session, will dynamically, allow that reply traffic to come back in. So the secret with modern-day stateful firewalls, is that we need to be able to control the initial flows of traffic because once that initial flow of traffic goes out, the reply traffic through the stateful nature of the firewalls, is dynamically, allowed back in.

6:44And most firewalls on the planet today are stateful in nature. They are going to remember the initial sessions going out, they maintain in memory a state of that connection, and then that dynamically, allows them to both recognize and allow that return traffic to come back in. And then beyond stateful, we have yet another category or two. I'm going to mush them together here, I'm going to call them application aware firewalls. Another term for this, which I'm also going to put here, would be a next-generation firewall. And this is the firewall that's not just looking at layer 3 and layer 4 information and doing stateful filtering, which most every firewall does, however, it also has the ability to take a look at the payload and the application layer, and then make decisions on that.

7:27So to really appreciate how a next-generation firewall or an app aware firewall can be leveraged, let's imagine we have a policy at our company that says clients can go out to Facebook and they can browse Facebook, but they can't use specifically, Facebook Chat. They can use Facebook general browsing but no Facebook Chat. Well, if we have a next-gen firewall that's application aware and it can tell the difference at the application layer about what is actually, going through, is it just Facebook or is it Facebook Chat, we could then have policy enforced at the firewall to allow certain types of traffic based on the applications that are being run, and then restrict others.

8:02So it's way above and beyond just looking at layer 3 and layer 4 information doing stateful filtering. And next-gen firewall with application awareness can now enforce policy based on the real applications that are being used. Other examples would include allowing a user to use Google services for searching, but maybe not Google Drive. And even though the ports may be identical for those, an application aware firewall can actually see what's happening at the application layer, and then either permit or deny that traffic based on policy, because it now has the visibility at the application layer.

8:33And it probably goes without saying but I'm going to say it anyway. The Palo Alto firewall, is absolutely, a very high-end, very capable next-gen firewall that can do packet filtering, stateful filtering, and yes, deep packet an application aware inspection of traffic, which makes it a very valuable resource as a security appliance in modern networks today. And since the firewall is actually, seeing the traffic is going between these zones, inside and outside, is there a possibility that a user either intentionally or accidentally, may try to download some malware or some harmful software to their system?

9:09Or could we have an attacker on the outside who's trying to break through the firewall? The answer is yes. That's all quite possible and very likely. And to help identify that that activity is happening and prevent it when possible, we are going to use a feature called the IDS or IPS. And the details of that, we'll cover in the very next video. So I'll see you in the next video for IPS and IDS in just a moment. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[JINGLE PLAYING] Let's begin with a question. If there is an attacker who is maliciously trying to get through our firewall or compromise our systems, yes or no, do we want to know about it? And I'm hoping the answer is yes. Now, unfortunately, many of the times, do we know about it? The answer is no until there's a compromise or a breach. Now, to help us identify, and also protect, against attacks in our network, we can use a set of technologies known as IDS, Intrusion Detection Systems, and IPS, which is Intrusion Prevention Systems.

0:37And in this video, you and I get to chat about what those are and how they can work. So let's start off with the acronym IDS, Intrusion Detection System. And a key element here with an IDS is this part right here, Detection. The IDS, when implemented as an IDS, can shout and yell and send alerts and let us know that there is an attack that's happening. But it doesn't either do, or have the ability to prevent the attack from continuing. And there's many different ways of implementing an intrusion detection system.

1:08One is we could take our existing devices, like a firewall that supports IDS, and we just train it to pay attention. If the software or the firmware, the hardware, all supports it and it supports IDS, we could train it to set off alerts when it sees malicious activity. And then those alerts can be responded to and worked with by the administrators and by the security team, or another option, if we don't want to have it in line with the traffic doing the IDS functionality-- we could have another device-- it could be a virtual device or a physical device-- that supports looking for and identifying malicious traffic or attacks that are attempted against our systems.

1:42And what we could do is we could take the traffic on the network and copy it over to this device. So maybe we're copying all the traffic for the VLAN or all the traffic that's coming in or out of the router interface. And we copy it down here to the IDS device. It analyzes the traffic. And then it sends off alarms, indicating that it found something. So the key here with IDS, whether it's in line, like this firewall is, supporting IDS, or it's a device that's just getting copies of the traffic, if it's configured as IDS, intrusion detection only, it can set off alarms when it sees malicious activity.

2:15However, it's not going to prevent the attack from continuing. And one common thought that many people have is, well, if it can see the attack, why doesn't it stop it? And if we configure a device that can stop the attack, that would then be implemented as an IPS, Intrusion Prevention System. So if we were going to implement a system as an intrusion prevention system, it has to have the ability to not only see the attack that's happening, but also to go ahead and prevent it from getting any further in the network. So if we're doing IPS, we couldn't have just a copy of the data being sent to that device because, if we did, and it seems an attack, it's not in line with it.

2:52It can't stop. So IPS pretty much means it's in line with the traffic that it's analyzing. So if it sees an attack, it can stop an attack. So if we implement it here on the firewall with the IPS services-- let's imagine we have a hacker out here on the internet who's trying to compromise us. And maybe that attacker is trying to reach these servers. And we have IPS enabled. So it's looking at the traffic. And it sees, well, that's malicious. The firewall can then go ahead and stop the attack right there and not let it get through to the servers, hence doing intrusion prevention.

3:24And based on the vendor of the IDS or IPS system, they use a variety of methods for looking at and identifying, hopefully correctly identifying, malicious traffic or attack traffic. And sometimes, it gets it right. And sometimes, it gets it wrong. And when an IDS or IPS gets it right, it's called a true positive, which means it saw something malicious, it called it out as malicious, and it got it right. Also, if it sees traffic that is not malicious, like just innocent traffic, no harm done, and it doesn't send off an alarm, that would be an example of a true negative.

4:00And in a perfect world, which we don't yet live in, all we want is true positives and true negatives, to have the IDS or IPS device correctly identify malicious traffic and not accidentally label innocent traffic as malicious. So if we have a situation where it's not going quite as planned and it identifies innocent traffic as malicious, that would be called a false positive. And if there was a situation where we are being attacked, and yet the IDS or IPS didn't recognize it as malicious, that would also be bad.

4:32That would be a false reading, and that would be a false negative. And those are tougher because if your IDS or IPS isn't setting off alarms, you'd have to have some other indication that there's a compromise or that the attack is happening. And so with any IDS/IPS system, there is going to be some tuning and tweaking with the goal of getting in the true category, accurate identification of malicious traffic and not sending off the alarm when innocent traffic is going through the network. And if the question comes up in your mind, well, does the Palo Alto firewall support IDS and IPS services, the answer is a resounding absolutely yes.

5:08And it does a fantastic job, at that. So for the next video, what I'd like to do is talk about a situation where we've got a user, for example, here that needs to securely access corporate resources, or maybe we have the headquarter site here and we have a remote site here, and we want to have a secure communication path between them and leverage the internet. To pull that off, we're going to use some flavor of virtual private network, which is the topic for our next video. So I'll see you there, my friend, in just a moment.

5:38Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:07Over the past few years, the use of virtual private networks to protect traffic between two different sites whether it's a user at their home office, or at home going to a corporate resource, or protecting traffic going from site 1 of a company to site 2, the use of VPNs is just grown, and grown, and grown. And so, in this video I'd like to chat with you, about some of the terms, and technologies, and options, that we have when using virtual private networks. And there's a couple of broad categories regarding virtual private networks, and let's start off with a remote access VPN, Virtual Private Network.

0:41Now the virtual private network itself, is going to allow us to provide authentication, to verify who's at each end of this VPN tunnel, and also once that tunnel is established, this VPN tunnel, to protect the traffic that's going between the two endpoints of that VPN tunnel. So a remote access VPN is when we have an individual device. Let's go ahead and have a user out here on the internet, and that user's got a PC, and they're connected to the internet, and that user wants to build a tunnel and have access to our corporate resources. So what they do, they run some client software on their computer.

1:14And then that client software would initiate and build a logical path, and that logical path that's going over the internet would be the VPN tunnel, and it would terminate here, at the firewall, meaning the firewall would be the other end of that tunnel. And so the firewall's not just going allow anybody to connect, it's going to require authentication of that user to verify who it is. And then once it's all set up all the traffic that's going back and forth, including the traffic over the internet, is simply going to be encrypted. So somebody can steal that data but because they're not being able to decrypt that data, they won't be able to make sense of it.

1:46And that way we're protecting all that traffic, even over untrusted networks, because we're using the VPN. Now in a Palo Alto environment, the way we would implement this remote access VPN, is through a service called GlobalProtect. And I'll walk you through how to configure that as part of our PC NSA and PC NSC Course Ware. But for now, just be aware that that's the method that we can use to implement a remote access VPN between a user and a Palo Alto device, or our corporate VPN endpoint. And regarding the VPN itself, there's actually a couple of different technologies behind the scenes that can be used to pull that off.

2:20We could use a technology such as IPsec, which is a standard based protocol for encrypting VPN traffic, or we could also leverage SSL/TLS. The same technology we're using when we go to a secure web server, we can use that technology as well. So when we set the firewall, we set the client to connect, between the two they'll negotiate which options they want to use, and as traffic goes back and forth over the VPN, it's encrypted and protected. Now one other element when we're talking about remote access VPN, is let's imagine this whole network here is the 10 network.

2:53Let's just go ahead and do a 10.0.0.0 with an 8 bit mask. So it's the 10 network. And let's also imagine this user right here has established the VPN to the firewall. My question is, which traffic should go over the VPN? Traffic just to the 10 network, or should we also include all traffic from this computer that's going to the internet and send that over through the VPN as well? And it depends on a few factors, and let me share with you some of those considerations. If we're worried about this computer being compromised and being connected to remotely from the internet, we may want to force all the traffic-- when the VPN is up and running, we may want to force all the traffic through the VPN, so we can analyze the traffic here and make sure everything's safe and sound.

3:34However, if this user is going over to a web server over here on the internet, the traffic would have to go through the VPN, and then back out to the internet, and then that internet server would respond back here, and then the traffic would go back through the VPN to the client. So there's some extra traffic and extra utilization if we're tunneling everything. So there's another option that we can set up, and it's called split tunneling. And with split tunneling we can set up a policy that says when this VPN user connects, only send traffic through the VPN tunnel if it's destined for this 10 network.

4:08And that way if this user is going to this server up here, at 23. whatever the IP address is of the server, that traffic to that server can go ahead and just go naturally as it would out to the internet, while any traffic that is going to the 10 network would go via the tunnel. So that's an example of split tunneling and controlling which traffic is going to go through the tunnel, and which traffic just goes directly out to the internet and doesn't have to go through the tunnel. All right, so for remote access VPN, our technologies are IPsec as we mentioned and SSL/TLS, and we also mentioned that we could use split tunneling with that.

4:43And there's some other options that are vendor specific that we could use as well for tunneling. But generally speaking, that sums up remote access VPNs. So let me clean this up, and let's talk about the other major category for VPNs. And that would be a site to site VPN. And here's the idea behind that. So once again, here we have the headquarters network. That's HQ. And let's imagine this is our branch office. We'll call that site 1.

5:14And for this scenario, let's say that the only connectivity between the headquarters site here and site 1 is the internet. So the headquarters is connected to the internet, site 1 is connected to the internet, and we want to have secure communications between users and devices at site 1 and users and devices over here at headquarters. So what we do is we have a VPN endpoint here. And once again, the Palo Alto firewall can do this handily. And we can set up an IPsec tunnel between the headquarters location and site 1.

5:44And for site to site VPN tunnels, like we're doing right here, the primary protocol we're going to use for that is a suite of protocols called IPsec. So that'd be an IPsec site to site virtual private network. And then we could also be very specific. So if this was the 10.1 network over here on the left with a 16-bit mask and over here at site 1 it was 10.2.0.0 with a /16 bit mask, we could configure the firewalls and the IPsec site to site tunnel to only forward traffic over that site to site VPN if it's going between 10.1 and 10.2, between those two networks.

6:21So a user at computer 2 could access a device or a resource over at the branch office, and that communication path would go through the switch, through the router, through the firewall, then encrypted through the tunnel, at the branch office site it would decrypt that traffic, and then forward it on to its destination. For the reply back, it would go back to this device, who would then go ahead and identify, oh, I need to encrypt this and ship it over the tunnel, because going back to the 10.1 network. So it encrypts the traffic, ships it over to its peer who decrypts it, and then forwards it along the way down to the original client.

6:52So these are the two types that we're primarily working with when we're working with companies. We have remote access VPNs, as we mentioned, and site to site. And there is, of course, other labels for VPNs when they may be used. Some of those are for anonymity-- somebody's on the internet and they don't want their internet service provider to see what traffic they're sending, so they build a VPN to some service. And there's also The Onion Routing network, TOR. That's going to use multiple layers of VPN. Most of that also is for anonymity. However, when we talk about corporate VPNs, we're primarily talking about remote access VPNs, to allow an individual user to get to their stuff at a corporate resource, and site to site VPNs, which logically provides protection and encryption of all the data and all the traffic going between those two sites.

7:37Now another key point, I'd like to chat about is, if we have a user and that user has access to data, which many of our users do-- that's why we're trusting with log ins and authentications and everything else to have access to data-- what is to prevent a user from taking some data which shouldn't be leaked out, and then forwarding it out the network to some other resource. And the answer is, in many environments, there's not too much stopping that. For example, a user just emailing a file to themselves, to a public email address, or to an email address that can be reached outside the corporate network.

8:09So hopefully our users will have security training, and they'll sign agreements regarding what they will and won't do. But what I'd like to do in the next video, is talk about what we can do, from a network security perspective, to prevent data loss. And that's with DLP, Data Loss Prevention. And that's the topic for our next video. I'll see you there in just a moment. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] In this video, you and I get to discuss DLP-- data loss prevention-- and how network security appliances and devices can help us in preventing that data loss. So one of the first elements regarding data loss prevention is to make sure we identify what data we don't want to lose. For example, we may have IP, intellectual property, or company secrets that we don't want to reveal. Or we may have PII, personally identifiable information, like social security numbers, and credit card numbers, and other data that we don't want released into the wild.

0:38And so, one of our first steps in protecting that data is security training for our users to make sure that the users know exactly what data they're dealing with and what the security measures should be as far as their handling of that data. And also to let them know that there is some auditing going on and that they're agreeing to all of that. So what are some methods that a user-- if that user is either disgruntled or they're blackmailed, what are some methods that a user could use to extract data from the organization and get it out to the wild? There's lots of options, including flash drives or just drives in general that they plug into their computer.

1:14And they just move the data to that flash drive. And they carry that flash drive out with them. So as a precaution to that, sometimes computers are set up in policy so that they don't accept USB devices. So in a corporate network with a corporate computer, if they set up the computer through policy so that it can't even accept the USB device-- not a physical lock perhaps, but rather just logically. You put in a USB drive. It just does nothing. That'd be one way to help protect against that. But other ways would be, as I mentioned earlier, they could just email it to themselves at a different address. Or they could reach out to an FTP or some other server that's doing file transfer services and just copy it out.

1:50And so, some measures that we can take in the interim with the security plans with data loss prevention is, first of all, we need to worry about encryption, because if a user has an encrypted session going out to a server on the internet, like HTTPS even, the firewall-- if it's all encrypted traffic, it can't really look at the application layer and see what the heck is going on, or analyze the data, or look for credit card numbers, or things that look like social security numbers, or whatever the identifying numbers are in your part of the world. So one of the elements we need to do to help with data loss prevention is to do some decryption.

2:23So our next generation firewalls need to do decryption of the SSL/TLS traffic just for a moment, so they can look at the application layer data and see what is it that's going out. And so if we have our email server here behind the firewall and the firewall is doing that analysis, the firewall can say, whoa, whoa, whoa, whoa, we have some data here that looks like it's matching credit card numbers or the patterns for credit card numbers. Or here's a file that's trying to go through, and we're not allowing files to go through. And the ability for a next generation firewall to actually do that decryption-- that is a double-edged sword because we may or may not want the firewall to be able to see some information.

3:01For example, if we've allowed this user here at this computer to go out to a banking website, it's very likely we are not going to want to decrypt that traffic and have the firewall be able to see information such as usernames, or passwords, or anything else that may be going on in that session. Or, if this client is accessing medical records, we probably don't want a firewall to decrypt that. So we'd have to set up in policy for some exclusions regarding what types of sites to not do the decryption on. But then, almost everything else, we'd want the decryption.

3:33And then we could start looking for specific patterns of data that represent sensitive information that should not be sent through the firewall. So once again, with decryption in place, if we enable that, that allows the firewall to do the application layer inspection, where it can see the data unencrypted and then look at the payloads in those packets. And then, because it's in line, it could actually stop it right there from continuing any further. And as we consider the security functions that a device can bring to the network-- so far at this point, the Palo Alto Firewall, as a next gen firewall, can do everything we've talked about up to this point.

4:07And so if you have a device that can do many, many, many things, does that mean you should do everything on that device? And it boils down to, is that device powerful enough as far as CPU and resources to do all that analysis and not slow the traffic to a crawl? And if the hardware and firmware is up to speed and can handle it, then the answer is absolutely yes. We could do a lot of different types of inspections and analyses on the traffic, including IPS, data loss prevention, terminate a VPN tunnel, and more. And so when we have a device that can do multiple things, that's oftentimes referred to as a UTM, which is an acronym for unified threat management.

4:46And that, my friend, is the topic for our next video-- unified threat management. So I'll see you there in just a moment. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] I've always been amazed at multitasking. And I went to a show once where there was a performer, there was a juggler, and a comedian. He had like 5 things going on all at the same time, and telling jokes. It was fantastic. Well, if we have a security appliance that can do lots of different things at the same time, that's also pretty impressive. And that can be referred to as a UTM, a Unified Threat Management system.

0:30So in this video, let's take a closer look at some of the functions and features that might be incorporated into a single package. So the concept here with unified threat management is having one device do multiple things. And I also want to point out before we get too far into this, is that if we have a system that is overloaded, for example, CPU is through the roof, it's almost out of resources, it may not be able to perform well at even one or two things, let alone five or six. So if you ever have standalone devices, like one device that does IPS, and a separate device that does VPN services, and a separate device that does data loss prevention, and a separate device looking for email security, it's very likely from a performance perspective that having dedicated separate devices will have a greater capacity for that type of analysis and work.

1:17However, it also might take some more management, because you have multiple separate devices. And certainly, it would have more cost if you had separate appliances, either physical or virtual, for each of those functions. So what I'd like to do is just do a quick summary of many of the features that can be found on a unified threat management system. And a few of those we've already taken a look at, so it might be a little bit of a reminder for a couple of those. One of the elements that we'd want in a unified threat management system is looking for malware, and if it sees it, to go ahead and deny it. So that malware doesn't get through our network and to our computers.

1:50So we can call that anti-malware. And as part of anti-malware, we'll also throw into that viruses and stuff like that that we don't want to be forwarded through our network. Another great feature of a device, if it's a UTM would be anti-spam. Where it could identify correctly spam or at least 90 plus percent of spam, and just drop it. So that way it never makes it to our users inboxes. So if we can stop the spam before it gets to the email server, we're going to prevent those email messages, which never made it to our email server, from actually, getting into the inbox on our clients.

2:24Another type of feature we might want in a unified threat management system, would be content filtering. And when I use the word content, I'm talking about fairly broad filtering. For example, do we want our users right here going to certain categories of websites? And the answer is, probably, not. We may have a corporate policy about what categories of websites are acceptable from corporate resources. So as an example, let's say we don't want our users to go to a gambling website. So we'll say, No gambling. So a unified threat management system with you URL filtering capabilities, could see a DNS request, for example, and through some intelligence from the cloud identify, whoa, this URL you're trying to go to is for a website that has been categorized as gambling, and then the firewall can say, nope, I'm not going to allow that traffic to go through.

3:09Or going back to our Facebook example. If we want to allow users to go to Facebook but we want to deny them the ability to Facebook Chat, we could specifically, based on application layer inspection, set up a policy that says, permitting Facebook the base services but we're not allowing Facebook Chat, and then our unified threat management system could enforce that policy. So they go and clean that up a little bit. Another example of a feature we might want on a unified threat management system would be DLP, Data Loss Prevention. We talked about that in the previous video. So with the UTM looking for strings of characters that look like sensitive information like birth dates or credit cards or identification numbers used by the country that you're in.

3:48If it's trained to look for those, it could then go ahead and stop that traffic, and not allow that traffic to be forwarded through the firewall. We'd also want our firewall to do stateful filtering, or sometimes called stateful inspection. And that's where we're allowing initial traffic to flow out, and then the reply traffic if it matches the correct reply traffic based on the client's requests, is dynamically, allowed back in. Well, at the same exact time, somebody on the outside who's trying to initiate a connection that's not a reply, would just be dropped by the firewall and not allowed further into the network.

4:21Other features on a UTM, would be features such as IDS, Intrusion Detection, and also Intrusion Prevention Services. And a lot of times when companies implement IDS and IPS , they'll start with the IDS. Even if it's in line, they'll start with IDS so they can just be aware of what's happening. And then they can start dialing it in, and tweaking and tuning it, and then they can enable the IPS functionality. And that way when they're actually dropping traffic that it identifies as malicious, hopefully, by that time they're not having false positives, and they're not dropping traffic that is actually, innocent.

4:52And that's how most organizations are going to move towards IPS. Is with IDS first, and then they simply flip a switch and say, OK, great now start dropping traffic if you see it as malicious. And another common element in the unified threat management system would be the support for VPNs, which we also talked about in a previous video. So one of the key elements to keep in mind is that, even if this device, A device, supports all those features, we only have so much CPU and RAM. And we want to be careful not to overload it with too many services and functions, especially, if a device is in line like this, where if it goes down or has a problem, he's just caused a problem for the entire network.

5:31So that's an overview of unified threat management systems that incorporate many security features in one device. And in the next video, you and I get to chat about endpoint security. So I'll see you there in just a moment. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] And welcome back. In this video, you and I get to chat about endpoint security. Now, we ought to start the conversation with, what exactly is an endpoint? An endpoint is some node that's attached to your network. It could be a Windows computer. It could be Linux. It could be Mac. It could be a server. It could be a mobile device, could be a printer, just the devices that are on your network and either providing or requesting or both services on your network.

0:30So what can we do to protect those devices? And the reason this discussion is important is because up to this point, we've primarily been talking about a network device that's standing in the middle between, for example, users and their computers and other network resources. But at the actual host, the endpoint, there are several things that we can do to improve security. So let's go ahead and jot down endpoint security. And one of those elements is to lock that computer down, meaning don't let users log on as root on Linux or as the administrator or with those equivalent rights on a Windows computer.

1:04You want to give them just enough rights so they can do everything they need to for their corporate responsibilities for the company, but no more. And that way, if they do get some malware or some other software, if they don't have enough rights to actually run or install the software, that's a great step towards preventing that machine from being infected with the malware. So limited rights. Another element we'd want on our computers would be to have some anti-malware software, which is looking for-- both on the disk and also in memory-- looking for viruses and malware with the intention of preventing it.

1:40And there's actually a whole nother level, or whole nother category of software that we can also use on our endpoints, including servers and workstations, and that would be host-based IPS. Now, sometimes, I've seen it as HIDS for Host-Based Intrusion Detection System, or host-based IPS. In either case, it is software that's running on that computer, and if we have a list of specific applications and services and calls that can be made, both to the registry on Windows, or to the file system on Linux, or to the network on either one, that host-based software that's running can enforce that policy.

2:16Another term for this type of protection would be a personal firewall or a software-based firewall, which could also identify and then permit or deny certain types of activities, whether it's to the file system or to the network, based on how that software is set up. And if there is malicious software that's identified on a computer, we then want to make sure we have the appropriate actions that can be taken against that system. And one of those is to do a quarantine, where, logically, the computer is removed from the network, so it can't damage or can't harm other systems until we can go over and take a look at it and see what's going on with that system.

2:47So that would be a network perspective regarding that host to quarantine it. Now, another option instead of a whole system quarantine is we could actually take the malware that's been identified and quarantine just the file, or we could delete the file, or we could set an alert. And hopefully, the alert would be associated with either of those activities, whether we're quarantining a file or deleting a file that was seen as malicious. And there's different methods that can be used to identify if software is malicious or not. And that same type of technology could be used on a network device looking for malware as well as software running on an endpoint.

3:20And one of those options regarding looking for malware would be signature-based, which has been around for a long time, and as vendors of security products identify new malicious software, they update their signatures so the software can check for it. However, that's not the only method that can be used to identify malware. There's also anomaly-based software, and with anomaly-based we're looking for exceptions like, hey, this is the norm from a firewall perspective. This is the normal traffic that we've seen over time, and now we're seeing this other type of traffic. That would be anomaly-based. Or in an endpoint, if a certain application makes specific calls all the time, and then all of a sudden out of blue it starts behaving differently, an anomaly-based system potentially could identify that difference and say, whoa, something's up.

4:00Another technique that can be used when looking for or trying to identify malicious software is to use container-based protection and analysis. So let's imagine a computer right here, and it's got some applications that are running. If one of those applications is malicious and tries to go rogue, it could affect and infect the whole system. But with a container-based model, what we could do is run each of those apps inside of its own protective little bubble. And if one of those apps starts to behave badly or is identified as malicious, we can go ahead and just shut down the bubble, and it is done.

4:31And that's how a container-based system, by keeping the applications separate and easy to completely shut down, can protect a system in the event we have a rogue application trying to run. And probably one of the toughest and most important endpoint devices that we would want to protect would be mobile devices. And some precautions and steps that we'd want to take regarding mobile devices is some type of a remote wipe feature. So if a device is stolen, we can basically send a self-destruct message, which it won't make smoke come out of it, but it can wipe off all the data on that device.

5:03So that way, we're protecting our sensitive data. Another great option from mobile devices to protect the data is full disk encryption on the mobile device and all of its storage. So that way, if a device is stolen, and if the attacker can't compromise the credentials to log in on that device, the actual media is just going to have a bunch of encrypted data that doesn't make sense to anybody, which protects any sensitive information from falling into the wrong hands. We'd also want some type of a mobile device management system. And with a mobile device management solution, we could implement our policy centrally and then have that pushed out and updated and maintained across all our mobile devices that are participating as part of that mobile device management system.

5:44And in the next video, I'd like to wrap up this set of videos with a discussion regarding the importance of identity and access management and also configuration management. So we'll handle that in our next video. So I'll see you there in just a moment. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:06In this video, I'd like to chat with you about identity, access, and configuration management. And let's begin this with an analogy of you and I-- this is us, you and me-- walking into a bank, and we want to make a withdrawal. Let's think about what would be required to actually get some money from the bank, assuming we are legitimately withdrawing some money. The first thing they're going to ask us to do is to prove who we are. So that ID could take several different forms. It could be a state issued identity card, or a driver's license, or a passport, or something similar to that.

0:40And we can refer to that process as authentication. And then the next portion, if we're asking for a withdrawal, they would want to make sure that we're authorized to make that withdrawal. So they know who we are, are we authorized to take the money out, and do we have money in the account, all that good stuff, and then refer this step as authorization. So, let's imagine that we have some money in the bank. We are the authorized account holders. We're authorized to take it out, so they give us the cash. So, cha-ching, we have a couple of units of money in our hand. We've got the money, and what are they going to do when they give us that money?

1:11Are they going to remember that they gave it to us? And the answer is absolutely yes, they are going to account for that and have it detailed that they gave us that money, and that step is referred to as accounting. So, in the networking world, that's referred to as AAA, the authentication, authorization, and accounting. So, here is an example. Let's say we have a user at this computer, and that user wants to go out to an internet resource. So, in policy, we can have a policy that says, if you're a member of group A, and you're using SSL/TLS, and also let's just assume you're not going to some malicious site, then, in policy, we can specify that we're going to allow that initial flow of traffic to happen.

1:48And then the reply traffic coming back, would be dynamically allowed back to the user due to the stateful nature of the firewall. So, how do the AAA components apply here? Well, if this user's traffic-- let's say user's at 10.1.0.51, and that traffic shows up here. The firewall needs to have some way of knowing who that user is. And so, in the background, maybe we queried Active Directory, or we're using some feature like User-ID, which is really amazing on the Palo Alto firewall, and maybe it's using all those methods and yet it still doesn't know who the user is behind this IP address.

2:20So, we have a feature we could use called Authentication Portal. And it basically stops the user in their tracks, gives them a screen, says, hey, who are you? And then the user can put their username in and password in. The firewall can verify that on the back end with, like, an LDAP server, and then once it verifies who it is, it then says, OK, great, this matches policy, you're a member of that group, and I will allow your traffic. So, that would be an example of the authentication, the firewall making sure it knew who the user was behind the IP address, the authorization based on the policy saying that traffic is allowed, and then, in the accounting logs, it's going to have a wealth of information, such as this user, whatever their username is behind that IP address, that user went to this site and that site and used these apps, and that's all accounted for in the log files on the firewall.

3:06And the AAA isn't just applicable for end users going through the network. It's also super critical for administering the network. So, for you and I, if we're managing this firewall, we're logging on either directly to the firewall or to the Enterprise Management system Panorama for managing a bunch of firewalls. We want to make darn sure that the interface is allowing us access there, has done the authentication, they know who we are, it's going to check for authorization, are we allowed to make those changes, and, after we do so, have accounting records that specify what we did.

3:37And one of the common themes in Palo Alto is zero-trust, meaning don't trust anything. So, if an administrator wants to connect and manage a firewall, they're going to have to prove who they are, and without that authentication and subsequent authorization, we can protect unauthorized changes from happening or unauthorized activity from flowing through our networks. And also, a big part of identity is having some type of centralized identity services, and in many cases, companies are using Active Directory, Microsoft Active Directory.

4:09So devices such as firewalls can make queries into Active Directory or go into a server that's looking into Active Directory like LDAP. And having a centralized database of our user accounts is super helpful, because that way, if a user, like user 1, has to change the password, they don't have to do it at five different places. They can do it in Active Directory or that centralized database. And then, if everything else on the network is referring to that Active Directory or that centralized identity store, that makes it much more seamless and less prone to errors as opposed to having to go to five or six different devices and change your password on each and every one of those devices.

4:43And another great way to help control access is to base it on groups. So if we give a group permission to manage the firewalls or we give a user group permission to go through the firewall, it's a lot simpler to maintain our environment because we have, like, group 1 and group 2 and group 3. We can simply add or take away users out of those groups to give them the access they need. So, as an example, when we have a group for admins, we may have a group that's associated with users in HR, human resources, and we may have another group that's associated with users in engineering.

5:20So, if we have a new person that joins us and they're in engineering, we simply add them to that group, and then they get the inherited rights and permissions associated with that group. Or in the case of admins, if we have a new admin, we simply make that person a member of the admins group, and then they are now a member of the group. They get those inherited permissions. So, that's an example of using a concept called Role Based Access Control, where the role or the group has the permissions, and then we simply add users to those groups. And if we've set them up correctly, then the users in those roles have the access and the provisions they need to do their jobs in those roles.

5:55Another important element regarding access is the rule of least privilege. So if someone's in engineering, hopefully they have enough rights and permissions to do everything they need to do in their job responsibilities. But we don't want to give them King Kong or excessive rights, because then if they're compromised or if their user account is compromised, that would then lead to additional risk and more loss, or potential loss. Also, a really great practice is periodic account reviews, because here's what could happen. We might have a person who's in the HR department, and they've been studying, and they're going into engineering, and then all of a sudden we say, you know, we're going to make you part of the engineers group.

6:31But if the procedure and the protocols aren't set up to do it correctly, we may leave that user as a member of HR and engineering, which wasn't our intention. So, doing periodic account reviews are going to help us identify if we have something I'd like to call privilege creep. And that's where an individual, simply based on time and being added to multiple groups and more groups and more groups and not having it pruned at any point, simply is getting too many privileges above and beyond what they actually need to do their job. So a periodic account review, including accounts that haven't been logged on to for months, is a good idea to help control and maintain proper access in our environment.

7:10And the last piece I would like to chat about is configuration management. So, let me clean this up a little bit, and let's focus our attention now on configuration management. So, let's imagine that we have a new device being deployed in our environment. Maybe it's a new router. Maybe it's a new firewall. Maybe it's a new switch. Maybe it's a new server. Maybe it's a new PC. Maybe it's a new printer, et cetera. If we are going to configure those from scratch, there's a good opportunity to not implement the best practices for security. For example, we may have services that are running on this printer that we're not even using, maybe as SNMP enabled, using some default passwords, and if we put it in, we now have a vulnerability on that printer by an attacker, or a very curious person on the inside, who could then do a port scan, for example, against that printer, identify the open ports, and then start to try to leverage or use the SNMP services that are available.

8:02Or on a Windows computer or a Linux computer or a networking device, what we want to have on all these devices is a hardened system, meaning they're not just open and waiting for an attack to happen and very easy to take advantage of. We want to harden them, so if we have services or features or functions that we should tweak or tune or disable, we want to do those when we deploy it. And so configuration management is going to help us do that. We can have a configuration baseline for new devices. Maybe we have a baseline for mobile devices of a certain type.

8:33We have a baseline for new switches, new routers, new firewalls. We have a baseline for Mac, and for Windows, and for Linux. And by having those baselines, we can start off with a more secure posture, and hopefully we have a centralized location as a database regarding those configurations, because there's one thing I can tell you about mobile devices and PCs and laptops and such is that, over time, they will change if they're not enforced via policy.

9:05So we'd want a system that says, I know what the configuration is, and also a method to periodically check and see if there's drift, or change, based on those standards and baselines that have been implemented. And if there's ever a change, that change should go through change control. And that way it's not just one person saying, I think this is a good idea. It's a team of people who all care, who all are stakeholders who can then analyze the potential change, do testing against that potential change, and then integrate that as part of the baseline, and that change control process can reduce the risk involved in a change to a system.

9:41So thank you for joining me in this set of videos regarding Network Security Fundamentals. And in the next set of videos, what I'd like to do is walk you through the implementation of some of these security features that the Palo Alto next-generation firewall brings to the table. It's going to be a great set, so you don't want to miss it. I'll see you there soon. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.