[image_with_animation image_url=”16034″ alignment=”center” animation=”None” box_shadow=”small_depth” max_width=”100%”]How can you protect your ship from an explosion? The same way you can protect your network from malicious users of course! The first step is recognizing vulnerabilities within your network. The second is distinguishing who has the responsibility of maintaining and reducing those vulnerabilities. When you reduce your vulnerabilities, you reduce the risk of possible exposure of those vulnerabilities to malevolent users. In this week’s Vblog, Raymond Lacoste dives deeper into how to better secure your network. (scroll down for video)
What is a vulnerability?
Anything that if exposed could have a major/minor negative impact on your organization. If someone was to recognize a vulnerability in your organization they can expose it. You are responsible for recognizing it in your own network. Do you have any left unchecked? You may not be able to eliminate these vulnerabilities but you can cover them and reduce the likelihood of possible exposure.
Who is responsible?
AWS is a shared responsibility model. This means that AWS is responsible for certain security requirements and YOU are responsible for certain security requirements. Which means that the biggest vulnerability to your network right now is YOU! It is crucially important to take the time to understand AWS’s shared security model. You need to know what you’re responsible for so you know how to reduce the size of your vulnerabilities and reduce your exposure to the malicious users of the world.[image_with_animation image_url=”16035″ alignment=”” animation=”None” box_shadow=”none” max_width=”100%”]Implementing security group and network access control lists with source of 0.0.0.0 for management access is allowing anyone in the entire world the ability to connect via SSH and RDP to your devices in the AWS environment.
Even though we can not totally eliminate this vulnerability, we CAN shrink it’s size to reduce the probability of exposure. For example, we can shrink the source from the public IP address range of your corporate network to a special source IP address range for management sources. Therefore, only devices with a source address in that range can connect via SSH to this EC2 instance in addition to needing the private key corresponding to the public key on the server to get access.[image_with_animation image_url=”16036″ alignment=”center” animation=”None” box_shadow=”none” max_width=”100%”]Right now you are probably giving IAM users more privileges than they need without even knowing it! Too often, the extra time is not taken to make sure that the least amount of privilege principles are enforced. Only give IAM users the privileges they need to do their jobs- nothing more. It’s a harsh truth, but something worthy of protecting against vulnerabilities!
The IAM Policy Simulator will look at different users groups or roles and their privileges and run a simulator on them. This is a valuable resource and tool to verify what actions IAM users are going to be allowed to perform with a set of policies and procedures attached to them. Again, reducing exposure will reduce your vulnerability![image_with_animation image_url=”16037″ alignment=”right” animation=”None” box_shadow=”none” max_width=”100%”]Another mistake you may be unaware you are doing right now is NOT having your S3 buckets and objects or EBS volumes encrypted. What will happen when these are exposed is a situation where an unauthorized user accesses the buckets, objects or the EBS volumes and takes that information because they can easily read them in plain text.
Even though we can not totally eliminate this vulnerability, we CAN shrink it’s size to reduce the probability of exposure. For example, we can shrink the source from the public IP address range of your corporate network to a special source IP address range for management sources. Therefore, only devices with a source address in that range can connect via SSH to this EC2 instance in addition to needing the private key corresponding to the public key on the server to get access.[image_with_animation image_url=”16038″ alignment=”” animation=”None” box_shadow=”none” max_width=”100%”]Creating S3 buckets with public access means EVERYONE in the entire world has access to your buckets! Internet access for the entire world is always a risk. Don’t believe us? Check out this article from The Register talking about
“Thousands of files containing the personal information of US citizens with classified security clearance have been exposed by an unsecured Amazon server.” Articles about leaky S3 buckets are appearing more and more. Why? Under access control lists permissions, people think they need to grant everyone access. Well this isn’t just everyone in your organization- it’s everyone in the world!
Do NOT use public access for S3 buckets and objects within S3 buckets unless you know without a doubt that’s what you want to do! Under your access control lists, if any of your groups or objects under “Public Access” say “Yes”, this means you have a leaky bucket. Get rid of it! Also check your “Bucket Policy” and change from “Public” to “Private”.
About This Instructor:
Raymond Lacoste has dedicated his career to developing the skills of others. His 17 years in the industry allow him to pull from experience in the areas of Amazon, Cisco, and Microsoft. For the last 8 years he focused primarily on advanced IT instruction. He is also the Cisco Press author of the TSHOOT 300-135 Official Cert Guide.
Raymond is a voracious learner and is constantly studying new technologies. To date he has passed over 100 exams. His certification wall includes various certificates from Amazon, Cisco, Microsoft, ISC2, ITIL, and CompTIA. Over the past years he has also been awarded, on numerous occasions, the Cisco Sirius Top Quality Instructor Award and the Cisco Instructor Excellent Award. Before becoming an IT instructor, Raymond was an aspiring golf professional, so golf is in his blood. When he is not teaching or designing and delivering the best in the industry training you can find him practicing or playing golf rain or shine or snow.
Hey, folks. We just wanted to take a couple of minutes to go ahead and discuss the three ways you have of managing your access points: the autonomous architecture, the cloud-based architecture, and the split-MAC architecture. All right, take care. No, I’m just kidding. Of course we’re going to talk about the three methods and their implications.
The first one is primarily going to be intended for those smaller organizations. Now, that phrase definitely has an asterisk associated with it, because when we think about an autonomous architecture, we’re typically thinking of a very small deployment, maybe only onesie twosie access points. There’s really no need to have a centralized architecture if we’ve only got one or two access points.
That’s really one of the key implications you want to keep in mind for the autonomous architecture. If you have a relatively small environment, maybe not a lot of heavy-duty usage on your wireless network, if you’re just talking about dropping in an access point so people can connect to it while they’re waiting for their coffee, the autonomous architecture is going to be perfect for that. It is very budget-friendly. These autonomous access points are considered extensions of your switch network. They are fully-functioning devices. They are self-contained. They even have the ability to connect your SSIDs to your VLANS.
Now, don’t let this graphic confuse you. Don’t let it fool you, because you can have an autonomous architecture that has hundreds if not thousands of access points. But the other implication you want to keep in mind with the autonomous architecture is that you lack any centralized control. If you’ve heard the cliché “too many cooks in the kitchen spoils the brew,” or the batch or whatever the heck it is they’re cooking, that’s what you’re going to run into with these autonomous access points.
They are fully self-contained. They are going to do their own thing. There’s no sort of coordination with their radio settings. We could actually have these autonomous access points bouncing up against each other, which is definitely a situation we don’t want. But if we’ve only got one or two of them — heck, even five of them — the autonomous architecture can be a perfect scenario for managing your access points, and that term is used somewhat loosely. You can manage them, you just have to manage them individually.
The second option you have for managing your access points is to utilize a cloud-based architecture. There are a wide variety of vendors that are now providing this solution. Perhaps one of the more popular ones is the Cisco Meraki devices. That’s primarily what we would focus on here, is looking at that cloud-based architecture where all of the managerial functions are available to you in the cloud. You know, those mythical things that are always floating above our head, spying on us. No, this is actually a good cloud.
I like to think that this scenario is extremely useful for administrators who are maybe volunteering for a nonprofit organization, the CIO who may not be able to be there on a daily basis, but they still want to provide some sort of architecture that they could manage remotely. That’s really where the cloud-based architecture proves its worth.
There are many other scenarios where this can be an extremely useful option. The key thing that you want to keep in mind with this particular architecture is, for lack of a better term, it’s kind of a hybrid between the autonomous architecture and also the split-MAC architecture. The autonomous side of it comes from the access points themselves. I can’t speak for any other vendors, but when it comes to the Cisco Meraki devices, those are very much considered autonomous access points. Yes, they are connected up to the cloud, but as far as the device itself, it is fully functioning, a self-contained device that you can log into individually and make settings there.
The reason I call it a hybrid is from the cloud dashboard you can actually manage all of your access points, and that’s something that’s simply not available with a traditional autonomous architecture. You have to go into each device individually to change its settings. With this, you also get the ability to coordinate your access points, which is something that leads itself more towards the split-MAC architecture, where you could look at two or three access points, look at their radio settings, and adjust them as needed and they’ll all work in unison with each other.
When you’re talking about a large-scale deployment, you’re going to want to consider that split-MAC architecture. It’s somewhat of a confusing way to describe this particular management technique, because you think, split-MAC? What the heck are we talking about MAC addresses for? What the split-MAC architecture essentially means is that we divide up the management process into two separate streams of data. What I mean by that is in the split-MAC architecture you’re going to have a wireless LAN controller that is going to be the orchestrator of all of the access points. All of the access points are going to get its configurations from that controller. That controller has the ability to see all of your access points and coordinate them appropriately.
The other stream is going to come from the actual real-time data, the actual wireless connectivity. That entire data process is going to be handled by the access points themselves. So while your wireless clients are connecting to the web and doing work like watching Netflix and checking out their Facebook, that is going to be entirely maintained by the access point. But as far as the managerial traffic, the frame information, security settings, reporting for the radio resource manager, all that is going to be managed via a separate data stream back to the controller.
The key implication with this particular type of architecture is of course cost, but that cost does have its advantages. What I mean by cost is lots of access points. Dedicated controllers. If we want to have some sort of disaster recovery, that’s going to include a backup controller. If we’ve got multiple locations, that includes multiple controllers. It is somewhat more expensive, but on the back end you have reduced overhead costs. Since you are centralizing everything, you don’t have to drive out to a separate location to fix an access point, to change its radio settings. You don’t have to log into a separate interface to maintain the security configurations. You can divvy that all out from the centralized location of the controller.
Before we had that cloud architecture, this was the de facto standard, but now, more and more organizations are actually looking at, okay, I’ve actually got three options. I could look at the autonomous architecture, a cloud-based architecture, split-MAC architecture. Pros and cons to all three of them, just like we find anywhere else in life. But you really, really need to look at it from a design perspective — which of course includes budget — to decide which one’s going to be best for your own organizational requirements.
That’s all we’ve got, guys. Take care.”Want to learn MORE of the best tactics to securing your network? Join us for our FREE 5-Day Network Defender Challenge starting December 4th and learn how to safeguard your systems from malicious users![image_with_animation image_url=”15040″ alignment=”center” animation=”None” img_link_target=”_blank” box_shadow=”none” max_width=”100%” img_link=”https://pro.stormwindstudios.com/5-day-challenge-LP?utm_sourc=blog”]Loved this video? Hated it? Tell us! We want to know! Add a comment at the bottom of this page with your ideas for next week’s VBlog! What do you want StormWind to talk about?