Designing the network security architecture is a task that will never truly be completed because as with many things the network, threats and security tools and processes evolve.
In order to future-proof your design though, you must set a baseline for what you want to protect and then ensure that the design can scale over time. A common failure in designing the network architecture is trying to find the silver bullet that covers everything. The problem here is that the threats you face today may not be the ones you face tomorrow and your network today does not look the same as it will tomorrow.
Think of your network perimeter like a castle during medieval times. You allow people from the outside to see them and you want to make sure you have multiple layers of defense setup behind them in case something fails. Like a medieval castle you have multiple layers of defense to stop an attacker and don’t rely on just walls to prevent attacks. That’s why castles had archers, high walls, big gates, people that dumped flaming hot tar on intruders below and my personal favorite, a moat filled with rabid alligators (if we could only find the cyber equivalent of a rabid alligator we’d all be safe on the internet). Even going back hundreds of years ago people understood the benefits of having security in layers and it’s no different today in information security. Over the course of this blog series, we’ll examine some tips for improving the design of your network architecture for a more secure perimeter.
In this part of the architecture, we need to concern ourselves with how we implement our network. It’s here that we start setting up our walls to prevent attackers from gaining access into our precious kingdom and pillaging our citizens (or users). One of the first areas we need to review is the front line – the systems that are actually in place to prevent unauthorized entry. These would be our routers, firewalls, load balancers, etc. Verify that these systems are running the latest and greatest updates and that the configuration on these devices is locked down to only the needed administrators. Since setting up a DMZ in your network is so important we’re going to dedicate an entire blog post just to that (so be patient).
Another thing that needs to be reviewed on these public-facing systems is if they’re resilient enough under attack. Do you have these core, public-facing systems clustered as to not allow an enemy to knock one down and leave you stranded? Just like our castle example, you never see a castle made of paper. They’re made of brick and stone to keep an enemy away and we need to think of this the same way when it comes to routers and firewalls.
One way to limit risk on your perimeter-facing systems is to have a “golden image” of the systems already in place before being sent out to the front line. If you’re using Apache as a web server there should be an image already created of this server that’s been vetted by your information security department. The same thing goes with networking equipment – does the router allow any to telnet to it from the outside (please say no). Also, before putting a system out on the internet make sure that it’s running all the needed security patches and add these to your “golden image”. Simple things like these suggestions can stop you from being owned. Now that we’ve taken this step, it’s still possible we’ve missed something. Let’s see what others can make of our systems while they’re out on the perimeter trying to peer in.
We also need to be aware of what others can see and do to our networks from the outside. It’s very important to know what attackers can garner from your organization before they actually use it against you. Like having a lookout on your castle’s towers, we need to be able to understand the threats that are coming and what they are.
In part 2, we’ll examine from a network design perspective the layers needed to keep guard and how to access the network securely.
Receive notifications of new posts by email.
We don not ask your personal information to access any of our resources.