Did you know Cybrary's video training is FREE? Join more than 2,500,000 IT and cyber security professionals, students, career changers, and more, growing their careers on Cybrary.
This lesson covers wireless local area networks (LANS). Some types of LANS are: - Station (STA) - Access Point (AP) - Cell This lesson discusses different methods of allowing access to a wireless LAN (such as authentication and shared keys). Participants also learn about firewalls and how they are used to protect wireless networks as well as methods for tricking hackers using production decoys such as a honey pot or a honey net. Encryption methods such as private key encryption are also in this lesson as well as public key infrastructures, digital rights management and network security protocols and technical security testing. [toggle_content title="Transcript"] Now let's talk a little bit about wireless LANs. We have our stations. These could be the device themselves, the mobile phone, a laptop, a tablet or a PDA. Connects the network with or through the access point, or the AP. Usually these work up to a range of 300 feet, or 100 meters. And then you've got some area where this communication is possible that is sometimes referred to as a cell. Similar to the way that mobile devices work with cell towers. When you're within that cell and the cell's map across a geographical area, then that communication is possible. As you go from one cell to the next, the signal gets handed off to the different communicating towers. For your wireless LAN, we have different ways to protect the transmission of our data. First thing we need to think about is authentication. If you've got an open system, there is no authentication, right? Anybody can connect. This is what you typically see in coffee shops or airports. A shared key. This is considered a poor method but certainly better than no authentication whatsoever. The problem with a shared key is that you need to get that key to the people that need to connect. So you have to have a secure mechanism for sharing the key with somebody else. Then we've got other things like AO211i which is considered a strong authentication mechanism. This means that we're using port-based access control and much more stringent requirements on detecting legitimate connections. Alright, so our next topic is talking about firewalls for our wireless networks. We want to make sure, first of all, that we have a separate firewall that does not bridge the wireless network to the wired network directly. If you do that, you need to be extremely careful, but generally you want to have a separate firewall that controls access from the wireless network to the Internet, or to some other resources within the organization. It would be difficult to have a firewall that manages the wireless side of the network and the wired side and provides all the necessary protection. It's certainly possible to do that, but you'd have to be very careful in case that firewall gets compromised, we wouldn't want to be able to have someone bridge those two networks together if that's not part of the network design. Intrusion detection systems are a vital component of any organization. We have several different types to choose from. Sometimes we mix and match these together. We start off with HIDS: the host-based IDS. A host-based IDS is important in conjunction with a network-based IDS, which is a NIDS. So they each serve different functions. We can think of the network-based IDS as more of a sensor. So it goes at your perimeter. Maybe it goes in the DMZ. You might have them in your database zone, or your web server zone. This looks for traffic on the network that is interesting to the IDS. We also would think about using a HIDS, or host-based because there could be situations where a host has some suspicious activity; maybe it's been infected with malware or a virus, and we can detect it with the host-based IDS first and then monitor its spread throughout the network with the network-based IDS. So they really do work very well together as providing some overlapping coverage, if you will. Some IDS systems work on a statistical basis. These are looking at the parameters of the actual traffic on your network. Trying to see where you've got a spike in traffic on a certain port, or a spike in traffic going to a certain IP address, maybe a known hostile IP address. Some IDSs, probably the majority of them, in fact, use signatures. The signature operates much like an anti-virus signature. There is traffic that comes across the wire. The IDS looks at it. If it matches the signature then an alert gets sent out. Or maybe you configure your IDS to do something else, but generally we want to get an alert when interesting traffic or suspicious traffic gets detected. Other IDS systems are known as neural IDS. This is not another variation of NIDS really, but you might see it abbreviated that way. The neural IDS is trying to learn what constitutes normal traffic and then compares that with what it thinks might be abnormal traffic, or suspicious traffic. So you might have a neural IDS that works in conjunction with your NIDS and your HIDS and then you can compare those baselines together because the management of an IDS system takes a long time. There's a lot of fine-tuning and other work that takes place over the period of weeks, months, maybe even years, to eliminate all of the false positives and to make sure that the IDS systems are catching those things that you're truly interested in. Alright, what about a production decoy, or a method to deflect attention away from your production systems? What we can do is install honey pots. Honey pot systems appear to be a legitimate computer system to the hacker. There's two kinds of honey pots. We have a low interaction honey pot where the attacker maybe finds this system on the network and they try to connect but the three-way handshake that normally would take place when we connect to a service doesn't actually work. That's the way the honey pot is designed. So it can fool an attacker for a little bit, and maybe deflect some attention away from the real production systems. We also have a high interaction honey pot which operates more like a traditional system where you can actually connect to it, possibly that honey pot could be even compromised. In general, honey pots are studied by the people that manage them to see what kinds of techniques and methods are being used by the hackers. If we put several honey pots together, maybe you've got a web server honey pot an email server honey pot, maybe a SharePoint honey pot. There could be lots of different combinations. All those things together creates what's known as a honey net. So it's a network of honey pots. This further goes into the direction of simulating a real network of systems or maybe you're simulating the kinds of systems that you might see in your DMZ. So a pretty interesting concept and definitely worth looking into as a way to provide a way to deflect attention from your production systems. Now we'll talk a little bit more about encryption. We've covered some encryption topics earlier in this course. One of the things that encryption does that's right off the top of the list is provide confidentiality. It also gives us protection for integrity and some authentication mechanisms as well. But if someone sees the data on the wire, they don't know what they're looking at, therefore the confidentiality is preserved. We can preserve integrity in some cases with encryption because even if the data gets modified; it might be detectable once it's decrypted, because then that data might be corrupted, or there might be other clues to let someone know that the data was modified perhaps in transit or while it was at-rest. Digital signatures use encryption. We get a lot of different features from digital signatures. We can verify who the sender was of a message. A sender could construct a signature in such a way that only the recipient can open it. So we get these different kinds of features and this provides a lot of value for the organization. We don't go into a ton of detail here about how the digital signatures work, but there's some level of understanding expected when you're taking the exam to know that the signatures can use symmetric cryptography as well as asymmetric cryptography and varying different combinations to provide the desired result. Public key encryption, or PKI; if we employ this as part of our digital signature scheme, then we know that perhaps only the intended recipient can now decrypt that message. So what about private key encryption? This is where we have a secret key that's shared between the sender and the recipient, or sometimes this is called a pre-shared key, if you're talking about it in a wireless context. This is generally associated with symmetric encryption where the same key is used to encrypt and decrypt. This is different than public key encryption. When we're using public key encryption we have a public key and a private key. The public key can be shared with anybody, basically because it's public. Then the private key is protected by the owner of that key. There's a mathematical relationship between these two keys. We know that the public key that we have only relates to one private key, and vice versa. Also, one of the other features that's interesting about this is that we cannot derive one key from the other. So if I had the private key I cannot do some operation on it to derive the public key. If I have the public key, I cannot figure out what the corresponding private key is. That's by design and that's what makes this mechanism and this technology so useful. We can provide confidentiality. For instance as a sender I can encrypt a message with a recipient's public key. When the recipient receives this message, only they can decrypt it because they have the corresponding private key. Or the sender encrypts the message with their private key. When the recipient receives it they can validate that it came from that sender because it is related to the sender's public key. As long as those private keys do not get compromised then the concept of confidentiality and authentication remains in-tact. We can also even bring non-repudiation into the mix because if I encrypt something with my private key and you can verify that by trying to analyze the message with my public key, then that proves that I sent it. Unless someone else has my private key, of course. But basically when we encrypt something we're trying to prevent availability for those people who do not have a right to know what that message contains. So let's talk a little bit about the infrastructure for PKI. The first thing we need to think about is the certificate authority, or the CA. This is what a user will interact with in order to get a certificate issued, where you get that private public key pair. They also use a registration authority to get the process started. So you go to the registration authority, enter in a bunch of information, basically, into a web form and then the certificate authority would then issue that key. If the key or the certificate gets compromised at some point in the future, you can revoke that certificate and then that certificate then gets listed on the certificate Revocation List, or the CRL. If you own the certificate, you might have to do that step manually, of course, because in most cases there is no automatic mechanism to know that a certificate is no longer valid. You have to make that entry and know that certificate authority will be referenced in the future when someone wants to use their certificate, it will say that 'this has been revoked' and the user will know that they should no longer try to use that resource. We also have the certification practice statement, or CPS. This basically describes how the certificate authority will issue certs and how they should be used. So there are some basic components here that you need to understand but it's pretty simple. Not too much detail is required, actually. Let's move along now to digital rights management, or DRM. This is a widely used technology that prevents making illegal copies of software, or music CDs, or game CDs, or other digitally protected media. Even PDF files could be protected with DRM. So this is using a certificate that might have been generated for a specific user. So you might have a PDF that's protected with DRM and it's coded in such a way so that only the owner of the credentials that are used to unlock that PDF can actually use it. Even if someone has the same PDF with their own credentials, you can't switch each other's files, and I can't open your file with my credentials and you can't open my file with your credentials. So it can produce a one-to-one relationship between the subject and the object that they're interacting with. So how do we deal with controlling our crypto systems? One of the things we can think about is using digital signatures in order to validate ownership and completeness confidentiality of integrity of various different types of documents. These could be contracts. It could be internal policies and procedures that you want to keep safeguarded. One thing that needs to be understood as well is that it's possible that you might want to use some sort of key escrow system. This is where management has a copy of all the crypto graphic keys in case one of their employees or one of the users of the crypto system encrypt something and that person; maybe they encrypt something and they leave the company. Now, nobody might have the decryption key in order to get that information back. That's why we want to have it escrowed. Maybe it's on soft copy and hard copy in a safe, just like we would do with our passwords, so that management can go retrieve that information and then decrypt the information that was formally encrypted. Each of the keys that gets issued to a user, or gets used for a particular purpose, should be managed separately. We want to make sure that we also think about how often that key is used. The more often a key is used, the shorter its lifetime should be. And this makes good common sense because if we reuse an encryption key again and again and again, that means there's more potential opportunities for an adversary to get that encrypted information and be able to figure out what the encryption key was. So the more often it's used, the shorter its life span should be. Whenever we give someone a key, if it's on a thumb drive or a CD-ROM, it should be on read-only media, which also makes good sense. You wouldn't want somebody to give you a key that's on read-write media because possibly the key could have been tampered with and therefore will cause problems when it's used. Now we'll talk a little bit about some of the protocols that provide security on our networks. You might be familiar with PGP: pretty good privacy. This is used for email-related encryption. For our websites and for other purposes maybe even VPNs; we have SSL: Secure Sockets Layer. A replacement that's supposed to be more robust and harder to crack for SSL is TLS, which is transport layer security. So knowing the acronyms, knowing what their basic functions are, is important for the exam. HTTPS uses SSL. So you're familiar with that again for going to websites like banks or credit card companies where you want to make sure that your entire session is encrypted so it can't easily be sniffed and decoded by a hacker, for instance. Then we have our IPSec VPNs. When I'm looking at a VPN; traffic on a network, all I should be able to see is the ESP traffic, which is the Encapsulating Security Payload. Authentication headers, or AH, are also used to validate the identity of the sender of that information. So it's another security mechanism that works with IPSec VPNs. So now if we think about certificates, we've been talking about them a little bit. If we think about the overall process that you would use to generate and use a certificate. We can go through these steps here. So the first step is to use the private and public key pair that was issued to create a certificate signing request, or a CSR. This CSR is then encrypted and emailed to the certificate authority. Then the certificate authority, or the CA, uses the CSR to encrypt a unique certificate for this specific computer. So there's a one-to-one mapping there. Then the fourth step would be to install that certificate that was issued to you by the CA. Now it becomes part of your certificate store. The last two steps involve updating your software to use this certificate, so maybe you're using it for authentication purposes, or it's being used in a single sign-on environment as a way to authenticate to other resources so you can prove your identity. Then you'll start your testing in step six. Maybe you're even modifying production software in order to use this certificate. So it's a pretty basic process. A lot of this happens automatically in most cases. Users are not really required to do all of the manual steps in most cases. Now let's think about some of the ways we can eliminate single points of failure in our environments. We cover a lot of different types of technology, a lot of different aspects to managing that technology in thinking about the ways that we want audit for compliance audit for completeness or making sure we're well within the law and regulations that we're subject to, but having single points of failure is still a problem that must be addressed. So we want to think about possibly having multiple power sources for the organization. I talked about that in an earlier section. You might even have multiple Internet service providers, or ISPs. That way, if one of them goes down, the other one can pick up the slack. We can think about multiple copies of servers. I have a mirrored server, or maybe I have a cluster of servers, so I've got multiple points of failure. If one server goes down there's still two more that are in the cluster perhaps. Maybe even a second server can go down and we can continue operating on just one of the original three servers. So some clustering technology allows for that kind of flexibility. We also have to think about our storage. RAID arrays give us the ability to survive the loss of one or more disks. This is critical because storage is such a vital component for our applications and the livelihood of the business itself. Now let's think about some of the testing that you might need to do in your environment. One of the obvious things that happens on a regular basis is some sort of a network scan. The network scan could be performed for lots of different reasons. One reason is for doing what's called a 'discovery scan'. We want to scan everything on the network to see if something new that we didn't previously know about shows up in the scan. This could be a good thing and a bad thing. If you do a discovery scan and you find that you've got a new computer on the network, you might want to investigate to find out exactly what that computer is. It could be a rogue system that someone put on the network but didn't go through the normal approval process, therefore that system might be vulnerable or might have some security risks associated with it. In general, when we do a network scan, we're just verifying that all the hosts we expect to see are visible on the network and that we know that this is a known quantity. Then, going one step further, you would do a vulnerability scan on each individual host. This would show you what kinds of weaknesses are present on those systems, based on their configuration, based on the operating system they're running, their patch levels, what they're used for, what they connect to, who the users are. There are lots of different factors which control or have some impact on the vulnerabilities that might be discovered. One technique that's used when you're going a little further than vulnerability scanning is to do a penetration test. Now you're taking those vulnerabilities that were discovered and trying to actually exploit them to gain access to a system. You might try things like password cracking. There's lots of different tools for this, and various reasons for doing it. You want to be able to verify that your passwords are not weak, for instance. A good strong password should not be easily cracked. We also need to think about log review. So that means that any time an interesting event, or a suspicious event happens, there should be a mechanism to generate an alert, so that somebody can look into it and decide if it's worth further investigation or not. [/toggle_content]