Blog: networking

By: (CISA, CISSP, Security+)

Well, maybe it used to be the question, but it is no longer a question to be asked. Scanning your network is an essential part of your security protocol to ensure that customer information is secured. So, since I need to scan my systems for vulnerabilities, where do I start?

Determine the Best Product to Scan Your System

There are many good products on the market to test for system vulnerabilities. The best method is to review different products and decide which product will take care of your needs. Not only does the product need to give you information on what vulnerabilities exist on your network, but it also needs to provide you with reporting that is easy for you to read and understand. A report is only good if you can take the information and make decisions on how to remediate the findings that it observes.

Rely on Network Vendors to Conduct Your Scanning

You may be thinking, I do not have the expertise to conduct these scans and read the reports, so what do I do now? This is where you will have to rely on a network vendor or third-party to conduct your scanning. You also need to ensure you have a contract and have conducted your due diligence with this vendor because they will need an administrative account on your network to perform an administrative vulnerability scan. User accounts can be used to scan the systems but will not give you a full representation of all your vulnerabilities. The goal is to mitigate as many vulnerabilities as possible, and a good administrative scan will help you reach this goal.

Remediate Vulnerabilities on the Network

Now that I have all this information, what do I do? REMEDIATE and DOCUMENT. Yes, those two words you always love to hear that strike fear in the hearts of man. Most, if not all, scanning software will rate the criticality of each vulnerability that is found on the network. Always start with the most critical and work your way down the list. Findings will require a knowledge of the systems you are running and an understanding of how to remediate the vulnerability. If you do not have the expertise to take care of these issues, a network vendor will need to be used at this point. Some findings require changes in Active Directory, registry settings or Group Policy. When changing these settings, making the wrong move can cause tremendous damage to your network. If one of these settings need to be changed, it is always a good practice to change the setting for one computer and test the change to ensure it does not cause issues with existing applications.

Sometimes settings cannot be changed due to the harm it causes in the system. If this is the case, document, document, document. Documentation needs to be completed that reveals the issue when you will resolve the issue, how the issue was resolved, and then verify that the issue was resolved.

Verification of the resolution is a critical part of the process. If a change is made in Active Directory, how do I know that the change has happened? If there is a change in Group Policy, how do I know if it has propagated to all the systems with the vulnerability? There are multiple ways to verify different vulnerabilities have been remediated, but the best way is to rerun a scan against the system.

Continue to Scan Your System

So how often do I need to run this scan? The frequency of the scan will be determined by your risk assessment and the size and complexity of your system. Sound familiar? Sounds like a statement that may come from your regulator or through guidance, doesn't it? If my system is not that complex, I would not have to scan frequently, but if it is complex, open to the outside world, and includes multiple users, I would need to scan more frequently.

Keep Up to Date with New Vulnerabilities

New vulnerabilities are being developed all the time, and a system that is scanned and is secure one day may be the target of a new vulnerability the next day. When you are between scans, be sure and keep yourself aware of any new vulnerabilities that may arise, especially those vulnerabilities that target your systems. Keep up to date by receiving emails from publications, vendors and regulators, and attending webinars and seminars that deal with information technology. Sound like a full-time job? It is!

So, to scan or not to scan can never be the question again.


 

We have a backup internet connection that is tied into our Test Lab environment. As a part of this, I needed to change the default gateway on all of my Test Lab VMs so that everything would go out the proper connection. Now, I could RDP into each one and make the change, but that is boring and this is a LAB! It’s time to play a little bit and see if we can change this efficiently.

My initial thought was to use a combination of "psexec" and "netsh" commands to change that IP. I figured out the netsh command necessary to change an IP address (including the default gateway) and just left the IP address information out of the command. Much to my surprise, it set the adapter to DHCP, yet statically configured a default gateway. For our LAB this doesn't work since DHCP doesn't grab an address, but at least now I know. So how do you go about scripting a change to the default gateway for multiple Windows systems?

Use a route add command, of course! Using psexec to push the command out, I ran “route add -p 0.0.0.0 mask 0.0.0.0 10.1.1.1” where 10.1.1.1 is my new default gateway. Much to my surprise, it changed the default gateway entry on the adapter without issue.