Don’t Panic: Cybersecurity Assessments for Network Engineers

Introduction

Security is difficult in the best of times. It’s hard enough to keep the IT infrastructure running, and organizations can’t watch everything and know everything about the latest security panic. They often need help from outside organizations that have specialized security expertise. The help usually comes in the form of periodic assessments of organizational security posture, usually called a security audit or assessment.

This article will try to demystify the security assessments for network engineers. It will talk about what security audits are, and how the network team can get the most from them. It is written for the benefit of a network engineer expected to interpret and act based on the reports received from the security team. Because of the very different skill sets between network engineers and security analysts, it can be difficult for security analysts to communicate what is actually needed on the networking side.

The Security Assessment

An information security audit is an audit of the level of information security in an organization. It is an independent review and examination of system records, activities, and related documents. These audits are intended to improve the level of information security, avoid improper information security designs, and optimize the efficiency of the security safeguards and security processes

Wikipedia

It’s important to realize that assessments are meant to help. Most security assessors and penetration testers are current or former IT professionals. They understand how hard it is just to “keep the lights on”. Assessors want to provide specialized expertise to help the organization. Assessments aren’t an attack on the core technology choices of the organization (network devices, operating systems, etc), either. Assessors assume that the organization made these choices for good reason, since they know their own business needs better than the assessors possibly could. A particular HPE Networking switch or Windows Server might not be patched, or there might be an issue with its configuration, but the assessor is not there to find fault with HPE Networking or Microsoft or their products.

Security assessments are more like a health checkup. Doctors have the required training to evaluate a patient’s health. They will do blood work, check blood pressure, etc. Based on this analysis, they will prescribe medication or treatments. Similarly, security assessors perform tests, take measurements, collect telemetry, and assess the current state of an organization’s cybersecurity posture. Based on that, they provide a list of actions the organization can take to enhance their overall security health.

There are essentially three components of the standard assessment for network infrastructure:

• Network device vulnerability scans. Tools like Tenable’s Nessus, Rapid7’s InsightVM/Nexpose, and Qualys’s Enterprise TruRisk Platform are commonly used.
• Manual or tool-based reviews of configurations of existing network infrastructure cover switches, firewalls, and wireless.
• Penetration testing includes external penetration test of internet-facing assets and internal network penetration test.

The next few sections will discuss these components of a security assessment. They’ll discuss what kind of reports they generate, what those reports mean, and how to use those reports optimally. The goal is to understand how the network team can maximize the value of the security assessment for their infrastructure.

Vulnerability Scans

A network vulnerability scanner is a tool that automatically identifies known security weaknesses within systems, networks, or applications by comparing assets against databases of known vulnerabilities, such as CVEs (Common Vulnerabilities and Exposures). The primary purpose is to detect potential entry points or weaknesses that attackers could exploit to gain unauthorized access to, compromise, or even just disrupt a network. The scanner enumerates open ports and attempts to get service banner information. In some cases, it will try standard communication patterns for well-known services, all for the purpose of identifying potential CVEs associated with those services.

Scans can be done against a system with administrative credentials (credentialed scans) or with no credentials (uncredentialed scans). Credentialed scans are considered high resolution. Reported software and operating system versions and patch levels are based on direct interrogation of the system. Because of this, they have a much lower false positive rate for CVEs. Uncredentialed scans, on the other hand, are lower resolution.Identification of software and operating system versions are based on some combination of service banners, packet structure of responses, open ports, etc. As such, they can have a higher false positive rate for CVEs.

As a general rule, standard server and workstation infrastructure, especially in Microsoft Windows enterprise architectures, will receive credentialed scans. For network devices, vulnerability scans are nearly always uncredentialed. Furthermore, modern network devices from companies like HPE Networking are specifically hardened against arbitrary enumeration over the network, so they report very little banner or versioning information. As a result, even the best, most reputable vulnerability scanners are only able to provide limited actionable security information.

Example of a vulnerability scan report for a set of network switches

In the above example, the first thing to notice is how many TLS/SSL “vulnerabilities” there are. These can happen for a number of reasons, most of which are benign and are essentially false positives. For example, if you drill into the “X.509 Certificate Subject CN Does Not Match the Entity Name” finding:

Example of a vulnerability scan result that is likely a false positive.

This is a standard case of the vulnerability scanner interpreting the mismatch between the IP address it was given to scan and the hostname on the certificate as a “vulnerability”. It is common for most industry-standard vulnerability scanners to have this issue. While it’s possible for an organization doing its own vulnerability scanning to configure their scanner to handle these situations correctly, it’s rare for an outside consultant to have the organization-specific knowledge to do this.

Their findings are not worthless, though. They can point out issues with best-practice hardening (e.g. HPE Networking’s library of system hardening guides). For example, see the “Self-signed TLS/SSL certificate” vulnerability.

Self-signed certs are a clear violation of basic hardening.

This is a clear violation of the HPE Networking’s hardening rule to provide a proper TLS certificate for network systems and to not rely on the self-signed certificate generated at first boot.

As a general rule, however, network engineers should take vulnerability scan reports of their devices with a grain of salt. The scanner is doing its best, but the network team needs to “rightly divide” the scanner’s findings and get what they can from its output.

Network Device Configuration Security Reviews

The gold standard of in situ device security reviews is the configuration review. It is a direct analysis of the actual configuration of network devices that highlights any insecure settings or violations of security best-practice. It isn’t concerned with optimization performance. Instead, it is only concerned with device and network security.

Network devices tend to be reviewed with the following coverage patterns:

• Firewalls: Usually all firewalls are reviewed, where “a firewall” is defined as a unique firewall configuration. I.e. high-availability pairs are a “single” firewall.
• Core switches: These are the “heavy” switches central to the network architecture. They are usually all reviewed, because of their importance to the overall security health of the network.
• Edge switches: These are distribution switches servicing endpoints. They are nearly always sampled, with the goal of capturing configuration “clusters”.
• Wireless: Since there’s generally only one wireless management interface, this is what is reviewed.

Configuration reviews are significantly more useful than vulnerability scans. They are based on either the exported text configuration of the device (e.g. for switches and firewalls) or inspection of the device’s configuration in its Graphical User Interface (GUI). Text configuration review are sometimes done manually by a human analyst against a predefined set of best practice controls, and sometimes they are done by a programmatic tool. GUI configuration review is always manual.

Manual Configuration Reviews

Manual configuration reviews are most accurate, but they are both more limited in scope and usually more expensive, since they require engineering hours to complete. This is especially true of firewall reviews, because of the complex rule sets found in their configurations. Manual reviews are generally done with respect to a specific set of industry-standard security controls (e.g. CIS Benchmarks, DISA STIGs, etc.).

Example of manual configuration review for a particular switch

Because these are confirmed by human review, their results are accurate. Non-compliance to controls can be ignored by network engineers if deemed acceptable by the organization, but the network team should document why they are doing so.

Example of a manual configuration review finding showing patching issues on an HPE Networking switch

The primary limitation of manual device reviews is their scope. There is only so much that a human can do within a reasonable (affordable) amount of time to identify security issues that might exist within a network device configuration. This is the reason why the next class of review, tool-based, exists.

Tool-Based Configuration Reviews

Tool-based configuration reviews involve some sort of programmatic examination of the device configuration to find as many security issues and potential CVEs as possible. One example of this kind of tool is Titania’s Nipper program. It is capable of parsing the exported configuration of many different network device manufacturers, identifying CVEs and common security issues. The primary goal of these reviews is to let the network team know if they have any serious hardening issues on their network devices. For example, it’s still all too common for organizations to keep cleartext services such as Telnet and SNMP v1/2c running on their network equipment.

Cleartext protocols such as SNMPv1 are very dangerous and a clear violation of hardening best practice.

Above is an example of a switch that is still using SNNP version 1, introduced in 1988 and long since replaced with more secure implementations. What’s worse, this device’s read/write community name, capable of providing full configuration access and control to this device, is something that could be guessed by a threat actor. This high severity vulnerability is something that the network team should pay special attention to and remediate immediately.

Because of their automated nature, these reviews can be less accurate, and as such, the network team will want to confirm any findings. On the other hand, they will have better coverage of a device’s potential vulnerability space and touch on the most important aspects of hardening. In this way, they are very similar to the credentialed vulnerability scan mentioned above, providing an accurate snapshot of compliance with security best practice.

Penetration Test

A penetration test (“pentest”) involves human attackers attempting to compromise as many different hosts, devices, and services as possible in order to document and report on the most critical vulnerabilities of and threats to an organization. There are two types of penetration tests: external and internal.

• External penetration test: This is a penetration test from the internet against an organization’s internet-facing assets.
• Internal network penetration test: This is a test from within the organization’s internal network. Its purpose is to simulate a compromised internal system, an insider threat, or a threat actor with a device on a live port.

External penetration tests tend to focus primarily on web applications and services, but network devices, especially firewalls/VPN services, are certainly in scope. Spend any time on Shodan, and there will be thousands, perhaps millions, of internet-connected devices with cleartext protocols exposed to the internet. If any of the network team’s devices is part of a finding in an external penetration test, this should be considered catastrophic and remediated immediately.

A device with the cleartext SNMPv1 protocol exposed to the internet as seen on shodan.io

Internal network penetration tests will have access to far more network devices, so its results will be even more relevant to the network team. If you have default administrative credentials on any of your network devices, you are likely to see those pointed out here, as well as the configuration review. Similarly, SNMP attacks are commonly part of penetration testers’ toolkits.

The penetration test and its corresponding report is the most relevant of all report types. Modern network gear tends to have hardening against precisely these kinds of attacks, so it isn’t common to see them mentioned in penetration test report. However, if network gear is mentioned in the penetration test, that is very bad news.

The network team should pay special attention to the pentest report’s findings. The most common finding for network gear is default administrative credentials, which can lead to all kinds of disruptions and denial of service attacks. The second most common finding for network gear is a poor choice of SNMP community names. This is especially dangerous for those communities with write privileges. Regardless, in nearly every case, penetration test findings are due to poor hardening choices in configuring the devices.

If a network team wishes to get an accurate view of their security posture and to know the likelihood that their gear would be part of a compromise of their organization, the penetration test, especially the internal network penetration test, is a necessity. Indeed, if added to a manual review of their devices’ configurations, this will provide the network team with the best possible assessment of their security posture.

Conclusion

It’s best to think of security assessments as health checkups designed to improve an organization’s cybersecurity posture. For network engineers, understanding the three main components of these assessments is crucial for properly interpreting and acting on their findings.

Vulnerability scans, while automated and comprehensive, have significant limitations when applied to modern network devices due to lack of credential access. Network engineers should view take these reports with a grain of salt and focus on the actionable items they do provide, especially those that intersect with good hardening practices.

Configuration reviews, whether manual or tool-based, offer valuable insights for network security improvements. These reviews align device configurations with industry standards like CIS Benchmarks and DISA STIGs, providing specific, actionable recommendations that network engineers can implement.

Penetration tests, particularly internal network penetration tests, provide the most critical information for the network team. When network equipment appears in penetration test findings, it typically indicates serious configuration issues like default credentials, weak SNMP settings, or compromised cleartext services that require immediate attention. A combination of security configuration reviews and a penetration test is the best way for the network team to know where they are and where they need to go.

The key for network engineers is to approach these assessments as collaborative opportunities to enhance security rather than critical evaluations of their work. By understanding what each assessment type can and cannot tell you, network teams can extract maximum value from these security health checkups and build more resilient network infrastructures.