Bench Talk

Most Internet of Things (IoT) devices rely on network communications to bring their unique functionality to life—whether it is a lightbulb you can control from your phone or your car notifying your dealer that it’s time to change its oil. Similarly, the applications we use on our phones, tablets, laptops, and workstations use networks to send and receive information from servers in data centers and the cloud. When designing the security of your environment and selecting these devices, systems, and applications, it is essential to understand the underlying network protocols they use for these communications. As the internet continues to evolve and mature, what was once considered secure might no longer be, so it is important to stay up-to-date on current technologies and update your devices or the protocols you permit as scenarios dictate. Attackers look for vulnerabilities in software and often start by examining the data sent between devices across the network. Using secure protocols helps ensure your data stays secret and your devices are protected.

Over the last few decades, many of these protocols have significantly evolved to be more efficient and more secure. It is important to understand when protocols change and always to use the latest, recommended secure protocols that prevent attackers from snooping on your sensitive data or gaining access to your network and devices. A secure protocol is one that has been designed to operate across untrusted networks—e.g., the internet— and ensures its payload is successfully delivered without tampering, snooping, or other interference. In some cases, you may be able to directly choose which protocol to use for an activity like whether to use Secure Shell or Telnet for remote administration. In other cases, you may need to dive deeper into your application or device to choose a specific version of a protocol to support—for example, when to disable insecure versions of the handshaking and encryption protocols secure sockets layer (SSL) v2 to v3 and migrate to current transport layer security (TLS) protocols. At a minimum, keep a list of the protocols that you use. In addition to responding to notices that you might receive from your device manufacturer, periodically search the internet for best practices.

Using secure protocols for remote administration is critically important especially as devices have expanded from on-premise, isolated networks to internet-connected cloud-based applications. One example of this is the migration from Telnet to Secure Shell for remote command-line administration. The evolution of technology drove this change. Years ago, network administrators typically connected to their equipment using Telnet over point-to-point serial connections via console cables. However, as remote administration shifted from serial cable to network connections, using Telnet was no longer suitable. Attackers could listen to a Telnet session, snoop on configuration information, and even steal login credentials to the device. Telnet is a very basic protocol, and its message is not encrypted. If you use your network directory credentials to log into a Telnet server on a device remotely, you run the risk of an attacker intercepting these credentials, which they can then use to access other resources. Secure Shell provides many of the same command-line based remote access capabilities as Telnet plus a lot more, including encryption, strong authentication using certificates, and resistance to spoofing. 

Choosing secure protocols is not just the responsibility of IT administrators—everyone is affected in some way. Take for example common web browsing. In July 2018, Google introduced a feature into the Chrome web browser that triggered an alert in the URL bar whenever a user visited a website without using encryption. Visiting a site using the unencrypted HTTP protocol resulted in a “Not secure” alert in the URL bar. Microsoft’s Edge browser also warns users when accessing a website over HTTP to “be careful” and that the site is unencrypted, although the message is somewhat hidden when compared to the alert presented in Chrome. HTTPS is the secure protocol for web browsing that encrypts communication between the client and server while also providing authentication of the server. In the past, you might begin your web surfing session in unencrypted HTTP, and then the website would redirect you to a secure page (HTTPS) whenever you were about to transmit sensitive information like checking out of an online store. This practice is changing though, and today more and more websites are encrypted all the time. When you type in https://www.google.com, for example, your browser will redirect you to the secure equivalent (https://www.google.com) automatically migrating you from the unsecured HTTP protocol to the more secure HTTPS protocol. Also, where this redirection isn’t possible, the browser will warn you with the “Not secure” alert.

Secure protocols play an important role in other sensitive activities like user authentication. For these lower level protocols, it might not always be straight forward to choose which protocols to use and which to disable, but it is important to keep tabs on these, nonetheless. Take for example protocols used to authenticate users to Windows resources—NT LanManager (NTLM) and Kerberos. Microsoft developed the NTLM protocol back in the 90s to facilitate the authentication between client and server, and Microsoft released several improved versions since the first. Through the Microsoft Active Directory Group Policy management tool, you can specify which version of NTLM to use and in what situations. For example, you can select a more secure version but negotiate to a less secure version in order to interoperate with an older device. With the release of Active Directory in Windows Server 2000, Microsoft introduced support for the authentication protocol Kerberos, which is now the default protocol for authenticating users to Windows domain joined systems. Microsoft currently does not recommend NTLM because it does not support current encryption modules and is susceptible to pass-the-hash and brute force attacks. However, administrators must still use NTLM for logon authentication on standalone systems that are not domain joined. It can be difficult to simply disable NTLM broadly for this reason and there are likely other systems and applications in your environment that rely on NTLM. In order to better understand NTLM usage in your environment, consider auditing the NTLM usage first—using Microsoft’s Group Policy tool—to better understand what dependencies you have on it. With this knowledge, you can then plot a course to disable support for the older versions of NTLM, restrict NTLM usage to specific systems, or eventually prohibit it all together.

Besides remote administrative access, web browsing, and authentication, there are invariably many other protocols that your devices use. Review your device information or contact your equipment manufacturer to understand what protocols they need and whether they are appropriate considering the sensitivity of the data they transmit or network on which they reside. To learn more, consider installing a network sniffer—like Wireshark—to take a snapshot of your network traffic. You may be surprised what you learn about your own network. While you might not be able to fully evaluate the security of any given protocol, you might be able to look for hints of insecure traffic—for example, viewing unencrypted network traffic and payloads sent from a device. This knowledge will also help you with your evaluation and selection of new devices and applications. With a bit of homework, you will rest assured that your devices will not introduce unwanted vulnerabilities into your network or environment.