As you go through major deployments, there is an increased risk to your network.  When things are in flux, your security posture is more vulnerable as there are many moving parts.    What can you do to reduce that risk before you deploy?  Well, being process oriented is a good start.  Following a process helps to ensure that you have accounted for all major events and met the requirements.  An event that is very critical from the security side, is the final review of device configurations.  Why is this so critical? Because many times things get missed and our networks are getting very complex.  You can logically divide your network to save on resources, group like traffic, add proxies, firewalls etc.  This adds to more room for mistakes.  Many times, these devices are configured without thinking about the security of the device but rather from the stand point of just getting them to work.

Before you deploy, I'm sure everyone does vast amounts of testing to ensure you have things configured just the way you want them.  Now you think its time to roll it out, but what about a final configuration review of all the devices before you deploy? If there are mistakes, you need to find them ahead of time right? Network modeling offers great potential, but even the best modeling tools can't support all the different device types.  It all sounds very simple, but how do you conduct a configuration reveiw if this is a major deployment and you have a couple of hundred devices or even if its a smaller deployment of 10 to 20?  What exactly are you looking for anyway? Here are somethings that I believe gets over looked in this area and will hurt your security posture.

1.  Test configurations left on the devices.  Someone set up a test vlan, firewall rule, account, acl, VRF etc. and no one remembered to take it out or even knew it had been created. It never fails, when your reviewing configs that you will find something leftover from testing.  Also, don't forget to confirm all the default account passwords have been changed.

2.  Logical Configurations being copied.  As many devices can be deployed logically, the ability to copy configs of virtual instances and use them again are built into most of them.  With this comes problems of carrying over unintended configurations.  In reviews, I have found many device instances that have been created that contained residual configurations from those they were copied from.

3.  Default settings left default.  In many cases, this may be ok but in others, it can be detrimental.  Why is that?  Because they are default and well known.  A quick Google can tell you what the default settings are for any device out there.  For instance, most IDes have the ability to configure how it handles fragmentation such as reassembly methods, buffer sizes etc.  More often then than not, these defaults are not changed or even realized that they exist.  That affords the attacker the advantage to know how to bypass your IDS.  It's the same scenario for many default configurations of many other devices.  The attackers know that many settings do not get changed and they are counting on it. 

4.  Services being left turned on.  Again, default configurations can get you.  Many times services are running from the initial startup and no one realizes it. It can also be they were turned on to troubleshoot and then not turned off again.  No matter what, a final review of what is turned on is extremely important.

5.  Protocols being allowed.  As you look at your network devices, one of the biggest offender I find is allowing protocols in because it's believed that you "need them" and a failure to understand how something works.  ICMP is a prime example.  It is amazing that people still see ICMP and think its just "ping".  A lack of understanding of the protocols and how they work is more often than not the culprit. 


If you have other mistakes you have found as you do configuration reviews, please let me know.  If you have a method that has streamlined this process successfully, please pass that along as well.