Category Archives: Vulnerability Scanning

Penetration Test – Does your business need one?

A penetration test is a method of evaluating the robustness of your IT security level by simulating an actual attack on your own systems.  Penetration testing can be a very valuable tool to help identify the path of least resistance into your company’s critical systems and is often an eye opening experience for management. If your company has not yet embraced the need for effective information security controls and penetration test might be just what the doctor ordered to raise awareness and build support.

Is your business ready for a penetration test?

The answer to this question depends a lot on the maturity of your information security program. If your business is still developing your information security program a skilled penetration tester may quickly gain access to all of your systems without much effort and you might only learn that you are highly vulnerable to attack and little else. My recommendation is to ensure you have conducted internal vulnerability assessments prior to conducting a penetration test unless you are using the exercise as a means to communicate your company’s exposure to attack. Unfortunately, sometimes information security is not taken seriously until there is a smoking gun and a targeted pen test can provide that.

Important items to keep in mind before signing up for a penetration test

  • Choose the company/individual that will perform the penetration test wisely. A lot of sensitive company data will be exposed so it is important to only deal with reputable people.
  • Make a confidentiality agreement part of the contract.
  • Scope the penetration test as desired to achieve your intended results. Possible penetration test scope includes: Full review, External Review Only, Internal Review Only.
  • The cost of a penetration test can be quite high so make sure your organization is ready to benefit from the results otherwise a full security audit may be a better choice.
  • Define objectives for the penetration testers to aim for. These objectives should be targeted at the highest risk business processes especially if you are performing the pen test to build support for expanding your information security program
  • Make sure senior management has signed off on the penetration test. Things can go wrong during a penetration test even under controlled conditions so it is an important CYA step to ensure your career does not go down the tubes.

Other Frequently Asked Questions about penetration tests

Should the penetration test be announced to your technical staff?

Usually it is a good idea to announce the impending penetration test to your technical staff so they will know it is occurring, be on hand to support if there are problems, and not escalate detected items to a higher level. A counter case of not notifying the technical staff can be made if you desire to assess the effectiveness of monitoring controls and wish to avoid having the staff on red alert.

How much information should be provided to the penetration testing team?

Penetration tests differ on how much information is provided to the testing teams. Some penetration tests are basically a blank slate where the technical team must discover everything without any inside information (black box testing) vs. other tests where significant network and system information may be provided (white box testing). Hybrid approaches are also possible where some generalized information is provided but the pen test team must figure out the rest. For external assessments I recommend providing in scope external IP addresses and phone numbers (if analog lines are being assessed) to avoid the problems that could come if the wrong targets are identified.

Can the penetration test have an adverse effect on my systems?

The answer is most definitely yes if the pen testing team does not take steps to minimize the risks to your operations. There is an inherent risk that comes with performing an activity like this but choosing experience testers and setting solid engagement rules can help minimize your exposure.

Are there any established frameworks for conducting a penetration test?

The Open Source Security Testing Methodology Manual (OSSTMM) is the best current framework to help guide a penetration test (including helping a client define the scope of engagement)

Should I have a member of my team witness the penetration test as a member of the technical team?

If you can negotiate this into the contract terms and plan to build your own internal capability to some extent this would be a great way to acquire on the job training at the same time the pen test is delivered.

Now that you have more information about penetration testing you can determine if your business is a good candidate to consider one vs. a standard information security audit.

10 Commandments of Vulnerability Scanning – Tips for conducting an effective vulnerability scan

Photo credits: hernandezmarzal














Vulnerability scanning is a critical business security control for identifying system vulnerabilities that puts information at risk. Vulnerabilities can exist at the network, operating system, database, and application levels so it is important that your vulnerability scanning tool(s) check as many of these layers as possible.

Ten Vulnerability Scanning Commandments

#1 – You shall not assume an accurate system inventory

Maintaining an accurate system inventory is a challenge even for disciplined IT shops. During the introductory phases of implementing vulnerability scans into your environment you should perform a scan of all of your internal, external, and RFC 1918 private addresses. By scanning all of your possible ranges you minimize your chances of missing systems that have not been recorded in your asset inventory or systems that have been added without authorization.

#2 – Remember the change control procedures

Vulnerability scanning is important but so is proper change control. It is important to follow disciplined change control processes for every scan so that the activity is properly documented and approved. Following proper change control procedures also helps pinpoint potential negative impact related to a vulnerability scan to a more precise time frame. For the vulnerability scanner personally not following established change control procedures could be a legitimate reason for termination.

#3 – You shall attempt to do no harm to thy own network

Performing a vulnerability scan is an inherently risky process. Until you have performed baseline scans and determined the robustness of your systems stability a cautious approach should be taken. This involves scaling up the level of the scans in addition to monitoring the systems being scanned for negative impact. Systems experiencing negative impact likely need to be upgraded or added to a scanning exclude list.

#4 – You shall configure your vulnerability scans with proper system credentials

The vulnerability scanning tool must be configured to have adequate system credentials to get the full benefit of the scan. Consult the scan setup documentation provided by your vendor to get help on the needed permissions configuration. If you fail to set up your scans with proper credentials you will get a false sense of security and only be scratching the surface of your potential vulnerabilities.

#5 – Remember thy scan frequency and make it at least monthly

New vulnerabilities are discovered on a daily basis so it is essential to schedule your scans on a recurring basis. It is good practice to define a consistent time period to perform your weekly/monthly scans to simplify change control and troubleshooting if problems occur. Regular scans are also required to validate that needed improvements have been put in place to lower the number of system vulnerabilities.

#6 -You shall not be careless with vulnerability scan information

Reports produced from vulnerability scans should be classified as high risk and access to them should be granted on a need to know basis. These reports contain the detailed information that would be attackers would love to have to compromise your systems. Do not make their job any easier.

#7 -Do not  falsely accuse your system administrators

System administrators need to be partners in the vulnerability remediation process and are essential for validating potential false positives. Stay on friendly terms with them and do not assume the vulnerability scan detail is 100% accurate.

#8 – You shall document your vulnerability scan exclusion list

When a system experiences negative impact from a vulnerability scan you will often times need to add the IP address to a scan exclusion list. The decision to exclude a system from the regular scan process should not be taken lightly and should be made visible so management understands the potential risk. Creating an exception process to document these situations and keeping it up to date is a best practice.

#9 – You shall decide what vulnerability severity level to focus and report on

Many of the items detected by vulnerability scanners are more informational in nature and may not require remediation. Decide ahead of time which level of vulnerabilities you will focus and report on. I recommend starting with severe/high level vulnerabilities only and only move down once those riskier items are under control.

#10 – Do not get frustrated at lack of progress

Implementing a strong vulnerability management process takes time. Do not get discouraged if improvement results are slow to come in the beginning. Stay focused on running a disciplined vulnerability management program and build the needed connections in the IT organization to make the process sustainable.

Have you started your vulnerability management program?