Olivier Le Moal - Fotolia

Get started Bring yourself up to speed with our introductory content.

How to perform a next-generation network security audit

The rapid evolution of networks has created a number of challenges for security admins, especially when it comes to network security audits. Expert Kevin Beaver offers pointers on performing a next-gen network security audit.

In the last few years, enterprise networks have evolved considerably. Everything from mobile computing to the cloud -- and not to mention all the new internal systems, services and applications -- are making today's networks more complex than ever before. Even the very tools used to manage network security can expand the attack surface and create their own vulnerabilities.

As many users often find out the hard way, complexity is bad for security, yet it continues on unabated.

One of the core challenges businesses face today is not knowing, at any given time, where things truly stand with their network vulnerabilities and business risks. If an enterprise is going to make tangible improvements in security, it has to take its network security testing to the next level. In this tip, I will explain how to get started.

Beginning a next-generation network security audit

First, it's important to remember the differences between security audits, vulnerability scans, penetration tests and information risk assessments. There are similarities among all of them -- namely to find and fix network security flaws before they're exploited -- but the approaches, tools, skill sets and time required for each vary considerably.

The most important thing to understand with security audits is what your company is trying to accomplish. We don't tell our radiologists and home inspectors to limit their scope based on what we assume we need; why limit the focus of network security testing to just one thing, such as penetrating the network from the outside, scanning a website for PCI DSS compliance, validating that audit logging and patching are taking place, or ensuring that documented policies exist? A combination of all the traditional testing methods is warranted; I call it a "security assessment." And through scanning, manual analysis, physical walkthroughs and interviews, I've found this to be the best approach. 

A fundamental law of network security is you cannot secure what you don't acknowledge. Before an organization can truly claim how secure its environment is, it must be certain that it's looking in all the right areas -- and doing so on a periodic and consistent basis. This doesn't mean your enterprise has to look at every single system on every network segment every single time, but it does need to focus on what's most important and the most visible. In other words, at a minimum, look at the most sensitive information on the most critical systems and work your way out from there. If you're eventually able to evaluate the security of all systems and applications -- both internal and external to your network, that's great. After all, if it has an IP address, a URL or -- given things these days -- an on/off switch, it's probably fair game for attack.

Tools of the trade

In order to get a true picture of security, stop relying on basic port and vulnerability scans. The business has to be willing to invest in tools that allow you to dig in further, which will require the following tools:

  • Network analyzers that can find protocol, system and user/host anomalies.
  • Password and encryption crackers that test the security of operating systems, mobile devices and whole disk encryption.
  • Personally-identifiable information search tools that can find improperly secured files on network shares and unencrypted laptops.
  • SQL injector and proxy tools for more in-depth Web application testing.
  • Database scanners that look for live databases that aren't accounted for.
  • Firewall rule base analyzers that can uncover core network flaws that would be hard to find otherwise.
  • Source code analyzers to uncover issues lurking in Web and mobile apps.
  • Exploit tools to demonstrate what can happen when certain flaws are uncovered.

Before you begin

Planning things out well in advance is critical to a good security test. It sets the expectations of everyone involved including management, developers and IT operations staff. Here are the main areas to address:

  • Who's the sponsor of the testing? Who will carry out the tests?
  • What will be tested?
  • From what perspectives will it be tested? (I.e., internal, external, with or without user authentication)
  • When will it be tested?
  • Is manual analysis required? (Periodic reliance on automated scans is fine, but total reliance without ever performing a manual analysis is dangerous, yet all too common)
  • About how long will the testing take? (It'll be longer than you think, especially when Web scanning is involved)
  • Will full system information be provided or will it be a blind test? (I prefer the former to ensure a definitive scope and that nothing gets overlooked)
  • What's your contingency plan in the event of a problem such as network denial of service or a Web vulnerability scanner filling up a production database?

Running the tests

It can take a book to cover this phase of network security audits, but here are four sub-phases your enterprise will want to run through:

  1. Reconnaissance -- to determine which systems, applications, people/processes, etc. need to be analyzed.
  2. Enumeration -- to see what's running where so you can develop a plan of attack.
  3. Vulnerability discovery -- to uncover specific flaws such as weak passwords, SQL injection and missing software updates.
  4. Vulnerability demonstration -- to show the significance of the vulnerabilities you find and how they matter in the context of your network environment and/or business.

Again, performing a manual analysis is a large and very important part of security testing. A monkey can run a vulnerability scanner; the real value comes when you use your wisdom and common sense to uncover and exploit the flaws that require human intervention.

Building an effective report

In this stage, the report you build outlines where and how things will get done, yet this step is often not taken as seriously as it should be. Even if all the greatest security gaps and exploits are uncovered, if these risks are not communicated well to others within the organization, then they probably will not be acted upon and the cycle of security breaches will continue.

Businesses are highly dependent on the outcomes of network security assessments, so continual improvements are a must.

From my own experiences, I've found that a formal report containing both an informative (i.e., not just a few sentences of fluff) executive summary and a listing of the technical details for each critical and noncritical finding works well; the more succinct the better. Never just hand over reports exported from security testing tools and expect that others will take the report seriously.

Anyone reading the final report needs to know three basic things:

  1. What the findings are
  2. Where they are present
  3. What can be done about them

Even with screenshots and other technical details, two or three findings can often be listed on a single page of the report. Just keep in mind that the more verbose the report, the greater the chances of something getting overlooked. Refer to an appendix, supplemental test data (i.e., PDF or HTML reports from the tools you used) or websites wherever possible.

Your time and your knowledge are all you have. Businesses are highly dependent on the outcomes of network security assessments, so continual improvements are a must. Sometimes it's your tools, sometimes it's your methodology, but it's often just a matter of getting better at what you do. Given all the assessments I perform each year, I've found that if you fine-tune your approach to security testing, you can get much better results in a shorter amount of time -- even with all the complexity present on networks today.

About the author:
Kevin Beaver is an information security consultant, writer, professional, speaker, and expert witness with Atlanta-based Principle Logic LLC. With over 25 years of experience in the industry, Kevin specializes in performing independent security vulnerability assessments of network systems as well as Web and mobile applications. He has authored/co-authored 11 books on information security including the best-selling Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance. In addition, he's the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. You can reach Kevin through his website www.principlelogic.com and follow him on Twitter at @kevinbeaver.

Next Steps

Understand the difference between security assessments and security audits

Learn more about network security audits in SearchSecurity's mini learning guide.

Get help preparing for a network security audit.

This was last published in October 2014

Dig Deeper on Real-time network monitoring and forensics

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

Does your organization have any additional network security audit best practices to offer?
Cancel
Network security architecture review
Netsec device configuration review
Log analysis

I did not find these in your otherwise fantabulous article.
regards
Ravi.R
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close