Building and maintaining an accurate inventory of your systems, devices, and applications is critical to ensuring that your technical security controls operate effectively across your entire organization. This is simply because you need to know what you have before you can begin to secure it adequately. Having an accurate inventory when you develop your security program enables you to know what machines to scan for vulnerabilities and subsequently patch. Also, you will likely query your inventory for which specific devices to include in your advanced security-information event-manager platform. Without a solid inventory, you might inadvertently exclude devices from your security controls that could give an attacker a foothold into your network.
The most basic inventory is a list of systems and devices found in your organization or environment. Enhance this list with security-relevant metadata including the make and model of the device and distinguishing characteristics such as:
More sophisticated inventories include additional metadata about a device such as:
Logical assets should include information that makes it easy to find the device or manage it in case of an incident. Examples of when you would use this information include:
The purpose of the inventory metadata is to aid in planning when designing new security controls as well as reduce the response time to discover impacted assets during a security incident.
Make sure your inventory is usable and accessible. For even the smallest inventories, give thought to the best data structures that organize and store your inventory that allow you to easily filter and query for specific devices based on the metadata. In some cases, a simple web frontend to your inventory database might be a good solution to abstract users from more complicated database schemas.
If you are not yet formally collecting an inventory, start with a simple list—a spreadsheet works fine—and evolve to a more sophisticated inventory management program as your needs expand. You will find there are many commercial and open-source inventory and asset management applications for all sizes of businesses and many offer demonstrations to test drive the features that best suit your purposes. Larger applications require maintenance and upkeep. It is important not to let the complexity of these programs overshadow the accessible and immediately usable benefits that even a simple, effective inventory list can provide. For example, a spreadsheet with data filters and pivots can quickly transform and present data into usable and actionable results without a lot of development. Of course, larger organizations that require multiple teams to regularly access and update inventory information might require a more sophisticated approach.
Consider leveraging inventory repositories already set up by other teams to uplift your own efforts. Finance, datacenter, or facility teams may already manage physical inventory for their own capital asset tracking, and this data may be a great starter to seed the data collection for at least a subset of your own data needs. Through cooperation with these other teams, you may be able to add assets that they might not collect—e.g., virtual machines—and augment their records with security-relevant metadata that enriches the larger repository.
Dynamically subscribing to another inventory repository might net you a treasure trove of inventory data already collected and managed by others. Be careful of one-time data extracts that could go stale over time. As your organization and own program grows, do not forget to scale your inventory processes as well lest they obsolesce. Store your inventory in an extensible and exportable format to facilitate sharing with other programs and systems. Even for smaller efforts, this will become important as your program grows from a simple spreadsheet into a custom database or commercial or open-source inventory application. Where possible, extend and integrate your inventory management processes into your move-add-change and change management processes to allow these programs to update your inventory data in concert with real changes to the environment.
A complete inventory that supports most security controls will represent both the physical and logical systems and devices in your environment. It is important to include the cloud assets as many of the same challenges to secure on-premise hosts also affect infrastructure as a service (IAAS) guests as well. Capturing cloud assets will require additional steps than those used to collect assets on your own managed network because the cloud assets might reside across multiple cloud subscriptions. However, the major cloud providers supply queries and application programming interfaces (APIs) that you can use to create dynamic reports or data extracts of your cloud assets given the right subscription authorization.
I often think of the inventory count as the denominator for measuring the overall effectiveness and reach of your security controls. Think about your security scorecard. Your security scorecard might include a metric representing the percentage of systems patched for known vulnerabilities. You might feel pretty good thinking you patched 85% of your systems, but you might not feel so good if you later find out that this metric only represents half of your total systems. Showing the denominator for security metrics is essential and helps tell the whole story. Take for example these made up metrics. If only 134 out of 200 devices connect to the newest logging system, then that might suggest that there is more work to do to enroll the remaining 66 devices. The dashboard on your commercial vulnerability scanner might report that it scanned 3,462 assets for vulnerabilities last week. Is that a good thing? It is tough to tell without the denominator. What if you are responsible for securing 4,000 assets or possibly 10,000 assets and the scanner only evaluated 3,462 assets for vulnerabilities? Having a complete inventory provides this denominator and completes the story of the overall effectiveness of the security control. Let's take one of the prior examples a bit further. Regardless of how many vulnerabilities are found on the 3,462 scanned assets, it is also essential to understand how many assets were not scanned and why. For example, was an IP range mistakenly left out or was it a conscientious financial decision attributed to license costs? Knowing when a control is operating for only a subset of assets and knowing why it is not operating for all assets is important. This ensures you do not have any gaps in your security coverage and helps design mitigating controls where necessary.
A good inventory will also help you meet your compliance and audit obligations. For example, in the past, the Payment Card Institute Data Security Standard (PCI-DSS) considered systems that held or processed credit card data as in scope of the PCI-DSS controls and audits. Identifying and tagging the systems in your inventory with PCI-DSS relevant metadata ensures you apply the right security controls for very in-scope system. When requirements are updated, such as when PCI-DSS expanded in-scope systems to include all connected systems, you can update your inventory to reflect these changes and always have confidence that your controls are applied to the right assets.
Lastly, consider taking your inventory management to the next level by recording asset dependencies. For example, you might link a web server asset to the database asset that it relies upon in the inventory database. More advanced inventory management systems help manage these dependencies, and these relationships will help inform your security decisions. For example, patching a database server for a critical security vulnerability might require it to restart. Knowing which web servers this restart will affect enables others to prepare in advance.
Building and managing a complete inventory of all your physical and logical systems and devices will prove useful to your day-to-day security and operations. With an up-to-date inventory, you will have fewer blind spots and more confidence that your security controls are appropriately scoped and deployed to just the right assets.
Following a recipe, like baking cookies, is one way to ensure consistency in the setup and configuration of your devices and systems, which in turn, reduces the possibility of introducing new configuration mistakes that could lead to unwanted vulnerabilities exploitable by an attacker. These recipes are baseline configurations that document in detail the exact settings that an operating system, application, or device should be configured. Use these well-defined configurations to automate processes that look for variance and configuration drift in a rapid and efficient manner. In this blog, we’ll look at how configuration baselines are an important tool to ensure your applications and devices are set up appropriately.
Configuration baselines are not at all new. Systems engineers and administrators have long relied on these templates to ensure that every system is configured identically. Prescriptive guidance, provided by system manufacturers and other subject matter expert groups, is an important place to start to ensure that your configurations are designed with security in mind.
Configuration baselines define how a specific type of device must be set up and are very detailed down to each input and variable. For example, configuration baselines define how to configure remote access to a device and what protocols to enable. Leveraging baseline configurations should reduce the overall operational costs of your devices because they ensure homogeneity across your fleet, which in turn, facilitates configuration through automation and other time-saving methods. It is expected that if one device works well with a specified configuration, the rest should behave in the same way. Proper configuration baselines improve security as well because through their development, they require a detailed review of every setting and often will result in a change of a device’s default behavior to a more secure posture depending on the use case. As a device operator, you can study and review the prescriptive guidance from one source, and then extend this knowledge to create appropriate baselines for similar devices from different manufacturers. This comparison method also highlights differences in capabilities between devices and may even influence which devices you choose based on their security features. Configuration baselines should include how to set up these security features and ensure that the devices and systems are appropriately hardened from attack. Take remote access for example, many devices support remote access for allowing system administrators and developers to configure them over the network. It is common for a device to support multiple protocols—e.g., telnet, secure shell, and web browser access—but not all these protocols are equally secure. For the most secure configuration, you would want to favor encrypted protocols that support modern authentication methods and disallow others.
Ensure your baselines support your organization’s security requirements and obligations by linking them to your security policy and standards. Your security policy is the cornerstone of your information security program and defines at a high-level what behavior is allowed and what is not. A good security policy is broad and covers multiple security domains relevant to your company or organization. Whereas the policy is broader and higher level, the information security standards dive deeper into each policy area. For example, you might include a single paragraph or two in your policy describing appropriate authentication principles but dedicate an entire five to six-page standard that describes in much more detail the approved protocols and permissible use cases and systems supported by your organization for these authentication services. The configuration baselines directly support the policy and standards and include the actual settings for how to set up the devices to use these systems. Lastly, you might choose to document appropriate procedures that complement the standards and baselines that include broader instructions on how to configure more complex systems and devices.
In our previous remote access example, the policy might describe the requirement for all devices and systems to encrypt network communications and require authentication for privileged access. Supporting standards would specify secure shell (SSH, over TCP 22) and hypertext secure protocol (HTTPS, over 443) as approved remote administration protocols and WS-Federation, Security Assertion Markup Language (SAML 2.0), and OAuth as approved authentication standards. Every type of device and system in your organization would have a unique configuration baseline created for it that defines the device-specific configuration settings that enable the device to support these standards. Configuration baselines can take many forms. The most simple is a table that lists every configuration element of a device and its preferred value. An illustrative baseline might include screenshots of configuration dialog boxes to make it easier to manually set up. To reduce the chance of configuration variance between devices, be sure to explicitly define how each checkbox, radio button, and field should be set. For larger installations, look for opportunities to automate the configuration through Application Programming Interfaces (APIs) or commands exposed by the device. Most enterprise network equipment is configured in this way. You can create a text file or XML document that includes all important configuration commands and settings and load this file into the device to ensure the equipment is configured in exactly the right way.
These configuration baselines are auditable. Many organizations use a redacted configuration file to demonstrate the secure configuration of a device to an auditor. Some vulnerability scanners like Qualys or Nessus can be configured to scan for configuration settings in addition to their vulnerability signatures. As a part of a broader Information Security Management System (ISMS), it is important to demonstrate not only that your devices are configured appropriately but that the configurations align with your security policy and program and these configuration baselines do just that.
You will likely find more diversity in creating configuration baselines for on-premise infrastructure than cloud-based services due simply to the variety of devices and systems offered by multiple manufacturers. Look to these manufacturers of the operating systems and large enterprise applications that you use for configuration best practices. The major cloud service providers expose APIs for their entire configuration, so it becomes much easier to write scripts and programs to quickly deploy a new system configured exactly how you want it and just like your others. Microsoft has published recommended security configuration settings for their current operating systems, which they offer as a download from their website. This zip file includes thousands of recommended settings to secure these systems. The Center for Internet Security offers a free download of recommended security configurations for a wide variety of operating systems and applications including Microsoft Windows, Linux, iOS, Apache, Docker, Microsoft SQL Server, Oracle, and many others. These resources are free and a great starting point for identifying important security configurations that you can customize to your environment.
Security configuration baselines help ensure that your devices and systems are set up in a secure and repeatable manner. Especially in larger organizations, where multiple people may be responsible for setting up devices, these documents ensure not only that the devices are set up appropriately and securely, but later provide a checkpoint to audit for configuration drift over time. Configuration baselines are a complementary component to security updates in a comprehensive and effective vulnerability management program and an important tool for system administrators and developers alike.
(Source: THINK A/Shutterstock.com)
Gone are the days of manually provisioning devices and equipment. In the world of the Industrial Internet of Things (IIoT), as millions of smart, connected devices proliferate the market, there must be a scalable and reliable solution to provision and manage devices. That’s what makes device management a must-have component of today’s connected ecosystem, and thoughtful device management needs to be designed into IoT systems. Here’s a quick rundown of IoT device management.
There are two main aspects of device management (DM):
DM for the IoT and for mobile devices (smartphones, tablets, etc.) might appear similar, but the former is much more challenging because of a highly heterogeneous mix of devices in any deployment in terms of operating system, application, and service layer functionality.
For cost-efficiency reasons, IoT DM platforms are typically cloud-based and often built into the IoT solution. While designing the application and service layers of the product, you have a choice to either customize them to a specific cloud platform (such as Amazon Web Services, Microsoft Azure, IBM, Predix) or design them as platform agnostic.
An automated device provisioning service registers new devices with geographically diverse points of presence, manages device configurations, secures devices by pushing over-the-air (OTA) patches and updates, and reprovisions devices when they reconnect or relocate. For secure and efficient access to device state information and health data and to facilitate analysis and business application development, a virtual replica of each device is maintained in the cloud. This replica is referred to by various names by various cloud platforms—for example, digital or device twins and device shadows. The digital replica in the cloud and at the edge are state synchronized with the physical device in quasi-real time. This mechanism gives greater visibility into device state, security posture, its software and firmware versions, and device health (Figure 1).
Figure 1: DM using a state-synchronized digital replica at the edge and in the cloud. (Source: Practical Industrial IoT Security, Packt)
Design for any IoT system must factor in the following fundamental aspects of DM:
Network-connected devices provide an excellent entry point for attackers unless adequate security is built in. As soon as a device is connected, the DM platform needs to verify that the new device is indeed trustworthy. During authentication, devices establish their identity by using credentials. Default user names and passwords are the least reliable credentials for the machine-to-machine world. Password-less authentication using keys and certificates and hardware-based root-of-trust are more suitable credentials to consider. Some original equipment manufacturers install certificates before shipping the product. Additional certificates can be added along the supply chain to create a chain of trust. Safe storage of credentials, run-time processing, power consumption, etc., are important considerations at this stage. After the device has successfully authenticated itself, the DM platform can begin provisioning to enroll the device based on its access privileges.
Typically, your device would be shipped with default configurations. Once deployed, the DM platform applies use case–specific configurations such as location, unique ID, and other application-related settings. For example, a device that is provisioned to track location and report on-vehicle telemetry in a fleet management system would need to be programmed with the vehicle’s license plate or vehicle identification number, and notification frequency. Remote programmability and secure application programming interfaces and configuration interfaces are important considerations at this stage.
From a control perspective, it should be possible to power off the device remotely or reset it to recover from error conditions or retire it. Remote commands to apply firmware updates, patch bugs, and reload are also necessary features.
Typical IIoT deployments involve thousands of devices installed in locations that are not easily accessible for in-person troubleshooting. To minimize the fallout of unscheduled downtime, it’s important to detect failures early. Most DM platforms come with continuous monitoring capabilities to collect device health data such as CPU usage, account activity, network traffic, and process-level input/output activities to detect anomalies. To support these data, the system should generate in-depth logging, run-time statistics, and process dumps for diagnostics for remote triage.
It’s unfortunate but true that no software is 100 percent bug free when shipped. After device deployment, bugs and security vulnerabilities are sure to surface. Besides, you might want to introduce feature enhancements for the software and firmware. Thus, throughout the product’s life cycle, it would be necessary to apply software and firmware patches and upgrades.
The challenge here again is that IoT devices are many in number, and they are often installed in bandwidth-constrained areas where connectivity is intermittent. It’s necessary to design products that can handle OTA updates during upgrade windows over encrypted communication channels for security.
Much like a device’s power supply module, DM features seemingly do not add any differentiating value to the product; as such, their inclusion tends to be an afterthought. These features are, however, critical to reducing downtime and improving run-time efficiency, which directly affects the financial bottom line. Many commercial development platforms from Microsoft, Wind River, Intel, and other vendors simplify the integration of DM, which system designers and developers can use.
As the cost of embedded networked devices falls—consider the Raspberry Pi as one example—they become ubiquitous. But, a hidden cost in this proliferation is that these devices can lack security and therefore be exploited. Without the investment in security, devices can leak private information—such as video, images, or audio—or become part of a botnet that wreaks havoc around the world.
Edge computing is a paradigm of shifting centralized compute resources closer to the source of data. This produces a number of benefits including:
As shown in Figure 1, the cloud infrastructure manages the devices at the edge. The Internet of Things (IoT) devices connect to the cloud through an edge device such as an edge gateway to minimize global communication.
Figure 1: The Edge Computing Architecture diagram shows the cloud infrastructure’s relationship to the connected devices at the edge. (Source: Author)
Statista, a German-based statistics database company, estimated that there were 23 billion connected IoT devices worldwide in 2018, and experts expect that number to grow to 75 billion by 2025. The Mirai malware, which targeted IoT devices and disrupted internet access for millions of people in 2016, illustrated the need for better security in these devices. In fact, when an attacker finds an exploit for a particular device, the attacker can then apply the exploit en masse to other identical devices.
As more and more devices proliferate to the edge, so do the risks for these devices. Connected devices are a common target for attackers who could be exploiting for attention or, more commonly, to expand botnets. Let’s explore the ways to secure edge computing devices.
To look at a device and understand how it can be exploited, we look at what’s called the attack surface. The attack surface for a device represents all of the points where an attacker can attempt to exploit or extract data from a device. This attack surface could include:
The attack surface defines the device’s exposure to the world and becomes the focus of defense for security. Securing a device is then a process of understanding the possible attack vectors for a device and protecting them to reduce the surface.
Common attack vectors typically include:
From Figure 2, we can see some of the attack vectors from the interfaces—network or local—various surfaces around firmware running on the device and even the physical package itself. Let’s now explore some of these vectors and how to secure them.
Figure 2: The image shows the potential attack vectors for a simple edge device. (Source: Author)
Attacking an interface or protocol is a multi-layered issue. There is the security of the communication itself with the cloud—including data security—as well as access security to the device through one or more protocols such as HTTP.
The Transport Layer Security (TLS) should protect all communication to and from the device. This type of cryptographic protocol covers authentication—to ensure that both sides can be specific about who they are communicating with—as well as encryption of all data to avoid eavesdropping attacks. This is ideal for an edge device that communicates to a remote cloud over public networks like the internet.
Given the speeds at which data moves over IP networks, hardware acceleration is a must in order to efficiently manage authentication and data encryption and decryption. Processors with hardware encryption acceleration like the TI EK-TM4C129EXL include on-chip crypto acceleration for TLS, ensuring secure communication with remote systems.
Using protocols like Kerberos for authentication can ensure that a client and server securely identify themselves. Kerberos relies on symmetric-key cryptography or public-key cryptography, both of which can be accelerated using processors that include cryptographic engines.
The protocol ports used with a network interface form one of the largest attack vectors on an internet-connected device. These ports expose protocol access to the device—for example, a web interface is exposed typically through port 80—and therefore provide information to the attacker on types of exploits to attempt.
One of the simplest ways of protecting these ports is with a firewall. A firewall is an application on a device that you can configure to limit access to ports in order to protect them. For example, a firewall can include a rule that prohibits access to a given port except for a predefined trusted host. This limits access to the port and helps avoid common attacks using protocol exploits such as buffer overflows.
Edge devices are becoming increasingly complex, performing more advanced functions than prior generations, including machine-learning applications. With this complexity comes the requirement to fix issues and release updates to devices. But, the firmware update process creates an attack vector. By implementing security measures for firmware updates in your edge security plan, you can mitigate the risks posed by attackers.
Code signing is a common security method used to prevent malicious code from entering a device. This entails digitally signing the firmware image with a cryptographic hash, which can be used on the device prior to the firmware update process, to ensure the code is authentic and has not been altered since the signing process.
The signed code can also be used at boot-time to ensure that the firmware in the local storage device has not been altered. This covers two attack vectors, attempting to update the device with an exploited image using the device’s update process and protecting the device against an image forced into the local storage device.
The processor used within a device can be helpful here, particularly if it implements a secure cryptographic engine for hash generation and checking. One example is the Microchip CEC1302, which includes a cryptographic Advanced Encryption Standard (AES) and hash engine.
The use of a Trusted Platform Module (TPM) is also beneficial. The TPM is a secure crypto-processor dedicated to security features and typically includes hash generation, key-storage, hash and encryption acceleration, and a variety of other features. One example is the Microchip AT97SC3205T, which implements a TPM in the context of an 8-bit microcontroller.
Creating tamper-proof designs can help detect if the device has been physically opened or compromised in some way. This also includes minimizing external signals whenever possible to limit the ways that an attacker can monitor a device in their possession and identify exploits. Attackers may attempt to monitor bus signals to identify secure information and, in extreme cases, may apply temperature changes to the device, change clock signals, and even induce errors through the use of radiation. Understanding the methods that a motivated attacker will use to understand your device will help in building more secure products.
With the state of cyber warfare today and the plethora of motivations, individuals and states have to exploit devices edge security is an uphill battle. But, implementing modern security practices and considering security at the start of product development will go a long way to keep your device safe. Early analysis of the attack surface of a device helps to identify where to focus attention in order to create more secure devices. You can learn more at the Mouser Security blog.
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.
Firewalls have long acted as a first line of defense for protecting network-connected computing devices and components from remote network-based attacks—much like a front door dissuades intruders from walking into your home. These network-based firewalls and routers were typically installed at choke points and acted as protective gateways between the internet and the trusted computers connected behind them. However, the proliferation of embedded devices, edge networks, and cloud applications have blurred these demarcation lines. Complex network architectures and topologies have made it more difficult to solely rely on these traditional network firewalls to protect your devices and applications. In this blog, we’ll look at understanding the network ports and protocols your devices rely upon and disabling those they do not need. I call this managing the surface area that your device presents to other networks.
Network surface area management is an important security best practice because it reduces the opportunity of an attacker to exploit a software vulnerability on your device. Take for example a webcam. This device is a mix of hardware and software and plugs into your network to remotely share video. The hardware includes the lens and image capturing electronics which relies on software to convert the pictures to a video stream. All devices such as these have firmware or an operating system that manages these processes. The webcam might also include additional features to send the image to a network video recorder or to allow users to log onto the device itself to see what it sees in real time. Additionally, the webcam firmware might allow remote access to install new features and deploy updates. Understanding how a device functions—even at a high level—is a prerequisite to adequately protecting it.
An important first step to effectively managing the service area of your devices is to understand what ports the device listens on and what network protocols it supports. Start by researching the device itself and look for supported network configurations in the manual or its technical support website. You can then expand your research by determining what firmware or operating system the device uses. For example, some embedded devices use the software BusyBox that provides common UNIX tools. Expanding your research into the device-specific operating system might also provide additional tips for how to disable unwanted services. Consider using a network scanning tool such as Network Mapper (NMAP) to remotely probe your device to discover (or validate) what ports the tool believes are open. You can search the internet for those ports unfamiliar to you and associate these ports with their host service. For example, a quick internet search of TCP Port 22 shows this port is associated with the secure shell protocol used for remote administration. These reconnaissance techniques will help define what network services your device relies upon and which of these network services are enabled and “listening” for remote connections on the network.
Table 1 shows a simplified representation of the network ports and protocols discovered on an embedded device.
Table 1: Example of the open ports and protocols used by a webcam.
Web portal to view camera
Encrypted web portal to view camera
The open ports in Table 1—TCP 22, 23, 80, 443, 554, and 5000—define the surface area of an example device that an attacker might successfully probe. Applications and services running on the device listen on these ports for inbound communication requests. For example, a person using a web browser to log onto the camera’s built-in web server to access its features. Attackers will often look for the easiest way to successfully exploit a device and start by scanning thousands of IP addresses looking for a response from a vulnerable device they can exploit. They do this by sending a specially crafted packet to an open port on a device. If the device responds in a certain way, then the attacker knows the device is vulnerable. An attacker might use a network scanner to scan all or the most popular ports and protocols of one device or an attacker might laser-focus their scan to just one specific port but target thousands of devices across the internet. Their goal is the same—probe open ports in hopes of finding a listening service that they might already have an exploit ready to use. Some malware is authored to propagate in this way. Once the malware has infected one device, it scans the network for other vulnerable systems before attacking the underlying service. The malware WannaCry is one recent example of this type of attack. A system infected with WannaCry scans its neighbors by probing Port 445 looking for a vulnerable Server Message Block (SMB) file transfer service to exploit.
You can lower the risk of a successful attack by using the following techniques to reduce the network surface area exposed by the device.
First, disable all unnecessary services. For example, you might be able to log onto the device and disable the Telnet service which correspondingly reduces the surface area because the device no longer listens on TCP Port 23 (the port commonly associated with Telnet). There are other benefits to disabling unwanted services as well. For example, disabling less secure protocols like Telnet and HTTP in favor of secure shell (SSH) and HTTPS reduces the risk of attackers intercepting unencrypted communications.
Next, consider enabling a host-based firewall. All modern, full-featured operating systems include some sort of a built-in, host-based firewall. Microsoft, Apple, and most Linux distributions enable these firewalls by default and make their configuration straightforward. However, if you need more instruction or want to fine-tune or configure advanced settings, there are many internet guides that can help. Even embedded devices now include built-in, host-based firewalls, depending on the underlying operating system used by the device. As an example, Busybox provides popular UNIX tools for embedded devices and includes options to install and enable the Linux iptables firewall.
Lastly, use your data flow diagram to identify candidate locations upstream of your devices to deploy or enable network- or cloud-based firewalls. Cloud providers include abstracted security services that provide firewall functionality. Look for terms like web application firewall or network security groups to start. Making these configuration changes outside of your specific device requires administrative access to network equipment or a cloud subscription. Care must be taken to ensure that any changes do not inadvertently affect other services or devices. Use these services and features to filter and drop unwanted traffic before it even reaches your device.
A good defense against attacks on your network-connected devices is an in-depth strategy that includes each of these techniques:
These techniques blend well with other security best practices such as ensuring that your underlying applications, firmware, and operating systems have the latest security updates applied and that your users are not overly provisioned privileged access. Please see my other security blog entries including Identify Anomalous Device Behavior through Logging and Alerting to learn more about some of these other techniques.
Security and other aspects of trustworthiness are of paramount importance to Internet of Things (IoT) networks. We are all aware of the well-publicized data breaches of the past, where millions of credit card numbers were compromised, privacy regulations were violated, or media were pirated. This type of data breach is embarrassing and costly to owners of the effected systems, but they didn’t result in physical damage. Now, with the additions of actuators to IoT networks that can affect the physical operation of potentially dangerous systems (locomotives, refineries, medical devices, reactors, etc.) under computer control, hackers will be targeting these systems, and the stakes to get network security right get much higher. It’s only a matter of time before some hacker compromises the security of an IoT system and causes significant physical harm.
Security is a key aspect of the trustworthiness of systems. Without basic security, other aspects of critical systems operations, such as privacy, safety, resiliency, and reliability, can’t be guaranteed.
IoT systems must be secure against attacks, especially IoT networks in control of life-critical systems. Engineers must pay close attention to all possible security threats and countermeasures to keep their systems secure. The first step is to understand the threat vectors. Hackers will attempt to attack IoT systems in many different ways, and the system is only as good as its weakest response. Examples of attack vectors include compromising IoT element hardware or software during manufacture; spoofing the authentication or configuration of nodes during installation; providing bogus software updates; eavesdropping on network traffic; cracking passwords; physical assault on IoT nodes; and various compromises to network management systems, policies, and processes. Threat analysis must take into account the likelihood of certain security threats as well as the consequences of the exploitation of vulnerabilities. Systematic analysis, including the preparation of detailed threat models, is best practice for assessing the security capabilities of IoT systems.
When the basic threat models are in place, system hardware and software must be designed with a rigorous approach to system security. Five key steps are required:
Good IoT security must start with secure hardware. The processor chips should have a hardware root of trust that functions to ensure the basic compute infrastructure can’t be compromised. Secure boot makes sure the software running on a processor isn’t compromised either. A Trusted Platform Module extends the hardware trust to the software platform, resulting in a Trusted Execution Environment, where application software can be run with confidence. All components of IoT systems, including chips, modules, boxes, software infrastructures, protocol stacks, security policies, and development tools, must be designed with security in mind. Security must also be of paramount importance to the various services and support infrastructures needed for IoT systems, such as communication networks, field-service organizations, management systems, and network operations centers. All aspects of IoT system architecture, development, deployment, and operations must consider security from the start.
Data in IoT networks must be secured in all stages of their life cycle. As soon as data are created (typically at a sensor), they should be evaluated for their security implications and treated accordingly. Often, this means choosing a cryptography standard and crypto key management system, and then applying strong cryptography as close to the data source as possible. Data in motion (traveling on wired or wireless links in IoT systems) require protection from eavesdropping and unauthorized interception or modification. Data at rest (stored in IoT sensors, edge nodes, or the cloud) also need appropriate encryption. Once data is no longer needed, the system should provide for its secure destruction. The appropriate application of emerging distributed ledger techniques such as blockchain can really help authenticate and control access to data in IoT systems.
Edge computing techniques are helpful in securing IoT systems, as well. Often, inexpensive sensors don’t have the energy, size, or budget to provide strong native encryption. Edge nodes, gateways, and fog processors are often the first stop for the data after the sensors perform sophisticated encryption on the data before it is sent to the cloud. Edge computing nodes are also ideal places to run security threat detection analytics and response software, greatly improving the security threat responses of IoT and network systems.
A word about testing: Testing is necessary but not sufficient to the creation of secure IoT. It’s important to test systems before, during, and after their deployment for security vulnerabilities. This testing could be traditional development lab or acceptance tests, but ongoing white-hat hacker testing is also valuable to identify subtle and freshly emerging security hazards. You can’t test security into systems whose architectures are inherently insecure.
Several resources are available for learning more about IoT security practices. The Industrial Internet Consortium has an extensive security framework document. The Open Web Application Security Project (OWASP) models of IoT attack vectors and Microsoft’s STRIDE model are also valuable. It is the responsibility of every IoT engineer to understand and design systems to address the security concerns. Security is the key component to creating a safe and trustworthy IoT infrastructure.
Privacy Centre |
Terms and Conditions
Copyright ©2024 Mouser Electronics, Inc.
Mouser® and Mouser Electronics® are trademarks of Mouser Electronics, Inc. in the U.S. and/or other countries.
All other trademarks are the property of their respective owners.
Corporate headquarters and logistics centre in Mansfield, Texas USA.