Penetration testing, also called a pen test, is a very important element of any IT network security plan. After all, if you setup all these firewalls and rules and you donât test that everything works right, are you sure that you are safe? Surely a mistake might have been made or something might not have been caught? This is where a pen test comes in - you (or a 3rd party firm) will act as a hacker attempting to break into your data, with notes and resources as to what actually succeeded so that you can plug holes accordingly following the test.
Before jumping into the network, consider your business needs - after all, if you break your mission critical applications accidentally during the test, your customers wonât be very appreciative. Ideally tests should be done either during hours that the business doesnât see much traffic or better yet in a test environment that has been designed to be an exact duplicate of the original environment. If you are using your production environment, be sure to set any ground rules that you have for the test. Do you want a specific piece of the business targeted, or are certain areas not an option? Also, do you want to know when the test will occur, or do you want the simulated attack to be completely random just like a real attack would be? These things need to be hashed out before starting a test.
After you have determined the elements of the business, next comes the matter of hiring a firm to attack your network or using your IT team. While hiring white hat hackers will likely test the most possible vectors, there is a cost tied to that. If you are a small organization you may wish to use your own team and utilities such as Metasploit or Cain & Abel - these two are free examples but there are many paid exploit tools (ex. Nessus) that go even further. Once the scope of work is determined as well as the parties that will be performing the test, determine the time frame and test the might of your network!
During the test you should expect no stone to go unturned and that your network security will be receiving the full wrath of the âhackerâ during the test. If the testing entity goes âeasyâ on you to try and give you a passing grade they will be doing you a serious disservice, as real hackers wonât do such a thing. This means that you should not ask or imply that the test should be lenient for ego or perhaps PR fluff - get the true story from these testers, even if it tells you that your security system is a complete failure. Also be sure to allow the tester to use non-network elements - remember that your firewall settings can be perfect, but if the tester can trick an admin or an employee with reasonable high-leveled credentials via phishing or social engineering, then you have an education problem to deal with to fully protect yourself. This simply canât be stressed enough - let the tester unleash everything he or she has on your organization so that you can fully prepare.
After the test is done, expect a report with results regarding what passed, what failed, and what passed but could still use some work. The tester should be able to replicate exploits for you after the fact as well so that the attack vector can be confirmed as working as well as showing IT what adjustments need to be made to network security. If a phishing attack was successful, prepare a training session with all employees to educate them about the dangers of spam. Even if you get a clean bill of health (i.e. the tester couldnât get through) be sure to ask what additional vectors could use reinforcement.