Hello and welcome. My name is Tyler McMann with Aruba at Hewlett Packard Enterprise company. This is our part 2 second video in our network security basics course, we're going to take a look at FIPS standards compliance and we're going to look at actually hardening or locking down administrative access on our wireless controller devices and access points. The same way we looked at locking down the administrative axis on our switches. Let's get started. [MUSIC]First things first, determining requirements for FIPS compliance, sounds exciting. Well, I'm just briefly going to cover this. This is a way to certify that the hardware that's being installed has been manufactured in the US or Singapore as part of our FIPS or Federal Information Processing Standard along with our trade agreement act, guaranteeing that the hardware was produced in a trusted environment. So tamper evident labels are applied and probe resistance 7200 mobility controllers are used, as well as other ways of hardening the software that's installed as well. Basically, what you would get if you were to purchase a switch or a controller or an access point with this FIPS TA standard for a slight additional costs. What do you get in return is you get this guarantee compliance that the hardware was produced in an environment that's trusted, that's basically it, as well as being locked down with some additional security features. Think of it as hardening the device before it even shows up at your doorstep. Which is pretty cool given that there's a concern between nation-states going after each other, the threat of governments attacking governments. With that aside, let's jump in and look at something that we can handle once through we do unbox the switch, unbox the controllers and the access points, and that's locking down administrative access. The administrative access is how do you get into the switch if you're racking and stacking them for the very first time and your power on and on. There's a number of steps that we're going to take to harden the device. Part of that is locking down the console port, which is that USB connection or the old serial port connection on older devices that allows us to configure, do password recovery. Essentially, it's your initial Root Access for setting your device up. We can set access policies to control other management access on the switches. This was in the form of using a secure management routing table or VRF, and a secure management interface alongside the console port, what we would call out-of-band or OOBM management. These ports are completely physically separated from the ports that you would use as a regular user, just plugging it in to get access to the network. External authentication authorization will be another checklist there. In the last[NOISE] series of videos, we talked about tack acts and radius, tack acts for IT people login into the device itself to set up the access point or to login. Really, the controller, to configure the controller through a command line interface. Then disabling local authentication to remove the option of somebody who gets physical access to the switch from being able to use that same console port or those out-of-band management ports which if you get physical access to a device and you know what you're doing, you can pretty much blow it out. Alongside that, we're going to do locking our services down, that means disabling unnecessary services. When we talk about the wireless world, we have access points. These access points could be standalone access points that you would deploy without a controller. They essentially just use one of their access points as an elected leader of the rest of them. We call this our instant access point clusters. Or in a normal Campus, you can get a lot more access points up to 1000 or 2000 of them that are all being managed and controlled entirely by mobility controllers. Not only are they managed through the Control Plane which dictates their stats, their configuration, sets up their keys, everything about them, but also the user data for users that are associated into these access points. We can tunnel their data across in order to have your user traffic always show up from this mobility controller standpoint. Between the access point and the controller they could be directly connected. In some circumstances that makes sense. But in most larger campuses, there's often a whole another network between these guys that they're tunneling across. For our purposes, the networking side of it doesn't really matter that much. It's just a matter of saying, "Hey, if I have untrusted traffic coming in, what can I do to protect my edge here from this user hacking into my network?" One of the things we do is we tunnel the traffic separately from the management traffic. Like having that out-of-band management interface, we have a control plane separate from the physical data plane of our users. To secure that control plane, we use encryption, specifically IPsec encryption when it comes to Aruba. Other vendors may use standard CAPWAP lab or LWAPP and run it over an encrypted TLS tunnel like DTLS or something like that. But for Aruba devices, a standard IPSec tunnel works just fine. In either case, the users traffic doesn't really see the light of day until it arrives at the controller. At the controller, that's where we can assign firewalls to evaluate the user traffic and determine should they be going to Facebook, should they be dropped? Are they using too much bandwidth, not enough? That's a very rough summation of everything that goes into this. We do have like a full three day mobility wireless fundamentals course where we explain all this and actually set up these controllers. For our purposes here, I'll demonstrate how to setup a wireless LAN. You can advertise employee networks. I'll show you how easy it is to set up that encryption and the authentication and everything, once you have these pieces in place. At your house, you may just have a simple access point that does all of this for you, but you need to put in your pre-shared keys any authentication. You have to configure it on every single switch. When you have 2,000 access points or 20,000 access points, in some of these larger campuses, that doesn't really make for a good day. For the authentication piece, we're still going to rely on some central server to keep track of usernames and passwords or to call upon an existing listing of employees, say in active directory or some LDAP server. That's all fine. If you remember from the last series of videos, Aruba does sell a AAA server that does this amazingly well. We call that the ClearPass Policy Manager or CPPM. For our purposes, we'll just call it ClearPass. When I refer to ClearPass, it just satisfies our AAA needs the centralization of authentication, of authorization, and accounting. To protect the console port on a controller, it's similar to what you would do on a switch. A mobility controller is like I had showed in the previous video. You've got these beasts of controllers here, and this is a 7210, a bit bigger than the old 7010 that you see there. The next version of this. Very heavy. But it's basically a switch. It looks like a switch. It's got multiple ports like you would have on a switch. It has high-speed up links that you have on a switch, and maybe some USB sticks for doing backups and things like that. Is also similar to a switch is how you console in to set these devices up out of the box using a traditional serial port or a USB port on more modern switches. Older switches been used a mini or micro USB port, but the newer CX switches use USB-C. Still USB, you just download a driver from Aruba's website, plug-in a USB cable, and you're up and running. You can console right in. If you want to do out-of-band management through an IP address on an interface rather than a console using a serial port, you can apply an IP address to this out-of-band management port if you'd prefer to do that. How do we protect the console port? Use password protection plus a high degree of physical security. What does that mean? It means put it into a switching closet, lock the door, make sure you rotate the keys on a regular basis. Be aware of who actually has physical access to these switches. Even your IT people generally don't all need physical access to the switch to do their job. Password protection can be easily circumvented if you can get to the physical box. If I can power cycle this box and I can get a console connection, I can blow out the configuration. Just by power cycling I can order shutting the power down. I can cause a denial-of-service and your availability goes out the window. When it comes to the access points themselves, every access point is going to have a reset button and it's going to have some sort of console connection on it. While the access points need their regular Ethernet ports to receive power and to plug-in their data to the rest of the network, the console port may look like anything like that port, or it may be a special four pin connector. Either way, you'd want to lock your APs away from prying eyes and from people being able to physically reach these things and get access to them. Hopefully that was not too in depth. In the next video, we'll talk about locking down services, similar to how we talked about it on the switch side, but from the perspective of wireless. I hope that this has been informative for you. We talked a little bit about FIPS and TAA. We talked about protecting the console port and we'll continue in the next video. Thank you very much.
