Online and Under Attack

Cybersecurity must be built in to protect connected security products

The December 2018 McAfee Labs Threat Report identified 45,000 new Internet of Things (IoT) malware variants in the third quarter of 2018. The number of attacks will continue to increase as more products are “IoT-enabled,” opening new communication pathways but also exposing vulnerabilities. Yet Gartner’s chief of research has said that, in 2019, most IoT security budgets will go toward fault remediation, recalls and safety failures. The reactive approach to dealing with IoT security must be transformed into proactive engineering practices aimed at locking down and securing IoT capabilities from the beginning. Security product manufacturers must understand the types of threats their products are exposed to when connected to the internet. Having this knowledge allows proper decision making regarding where to spend limited budget resources.

A look at the cybersecurity threat landscape shows a trend toward new attack methods. For example, automated malware is beginning to target IoT products to mine cryptocurrencies. The goal here is to collect as many vulnerable devices as possible and use them all for a single purpose. Volume is critical, so attack scripts are constantly searching for newly connected products that have known vulnerabilities. Ransomware attacks also introduce new concerns for security product manufacturers. If automated attack scripts can compromise a product and use it for malicious purposes, these same scripts can also be used to shut down product services and render them useless without payment of a ransom.

What this means to security product manufacturers and consumers is that, as soon as a product is connected to the internet, it is exposed to a torrent of attacks. There is no time to properly configure the security of a product if it is shipped with a known weakness. It will simply be compromised from the start.

Establish Product Cybersecurity Goals

The starting point for any cybersecurity program is to establish goals. These goals are defined by examining the impact areas associated with a security breach. A breach might result in a diminished reputation, financial loss, productivity loss, negative safety consequences, or fines and legal penalties. For example, a critical set of cybersecurity goals might include:

• Maintain product availability – Guard against ransoming, denial of service and misconfigurations that render a product, service or feature unusable
• Protect sensitive data – Guard customer and stakeholder data from compromise, whether it resides in the cloud, in a mobile application or on a device
• Protect privacy – Guard against eavesdropping on customers through video, audio or even data hijacking
• Protect from automated attacks – Apply basic cybersecurity hygiene to safeguard products from being hijacked into botnets

Accomplishing these goals requires a methodical cybersecurity development program. This program should provide product management staff with the knowledge needed to understand the unique threats to the product line and to be able to translate that knowledge into actionable product requirements.

Understand the Threats

Product managers should understand the specific threats to their product line. Not all threats are applicable to all products. For example, the threat that an attacker might tap into a video feed to surreptitiously monitor their victim may be limited to surveillance (audio/video) equipment. It is a good practice to document threats based on a set of criteria. One threat profile methodology known as Octave Allegro from Carnegie Mellon supports building a threat profile by defining the actor that would exploit the threat, how that actor would attack, the motive for doing so, and the resulting effects.

A key step in understanding threats is gaining a better understanding of the specific types of attacks that might be executed. Table 1 provides a sampling of attack types that are used on the Internet to gain access to IoT products.

Table 1: Sample Attack Types Used to Gain Access to IoT Products

Attack Type	Description
Credential extraction	Obtain credentials which can be used to communicate to the device while impersonating a legitimate user, or which can be used to communicate with other hosts while impersonating the device
Data collection	Extract private, sensitive, restricted or otherwise valuable data from the target device
Denial of service	Evade detection of pirate tools and avoid other defenses; usually done by variations of techniques in other categories that have the added benefit of subverting a particular defense or mitigation
Device hijacking	Subvert the device’s resources for the attacker’s purpose; this includes the device’s network connectivity, computation capabilities and physical capabilities, if any
Lateral movement	Access, control and gather information from remote systems on a network, possibly including execution of remote access tools; movement across a network from one system to another may be necessary to achieve an attacker’s goals
Malicious code execution	Execute a code which is not an original code of the device but is maliciously plugged into it for execution; this code is intended to either take advantage of a device function or just harm it
Malicious login	Gain control of the device in the form of an interactive login session
Malicious update	Gain control of the device in the form of an update which modifies the device’s behavior to suit the attacker
Privilege escalation	Obtain a higher level of permissions on a system or network; adversaries enter a system with unprivileged access, taking advantage of system weaknesses to obtain local administrator or root level privileges
Reconnaissance	Gain knowledge about the system and the internal network so the attackers can orient themselves to what they have gained control of and to the benefits the operating system can provide to their objectives
Remote exploitation	Exploit a software weakness to make the device execute code provided by the attacker over the network
Traffic interception	Passively intercept network traffic from a device via a man-in-the-middle attack or by eavesdropping on unencrypted communication
Traffic manipulation	Actively modify data sent and received between the device and other hosts by intercepting, modifying, replaying or otherwise manipulating network traffic

Once the members of a security team understand the types of attacks that a product might face when connected to the internet, they should document the threats in a consistent manner that can be communicated to the product development team. The process of understanding product-unique threats is known as “threat modeling.” Although this process can seem complex, there are tools that can help security analysts. The Open Web Application Security Project (OWASP) provides a free threat modeling tool known as Threat Dragon that allows users to diagram systems and generate threats and mitigations. Microsoft also provides a threat modeling application that can be downloaded at no charge. With this, users can create templates that can be reused for new product versions. These templates can define standard information flows, types of threats, components, and attribute values associated with the components of a product.

Rate and Prioritize Threats

The mere existence of a threat does not mean that action must be taken to mitigate it. A risk analysis process is an essential component of a cybersecurity program. Product teams should be able to evaluate each individual threat to determine a risk score. The risk score is based on the likelihood of the threat being realized and the impact of the threat. A standard calculation for risk score is:

risk=likelihood*impact

OWASP again provides useful information that can be used to better understand all that goes into determining the likelihood of an event occurring. It offers tips on understanding and evaluating the skill level and motivations of an attacker, as well as ways to quantify the impact of an event.

Microsoft also provides a well-known methodology for calculating risk known as DREAD:

• Damage – What amount of damage (physical, monetary, reputational) would occur?
• Reproducibility – Can the attack be reproduced easily?
• Exploitability – How difficult is it to execute the attack?
• Affected users – How many customers or stakeholders will be affected?
• Discoverability – Is the threat well known? Can anyone discover it?

Prioritization of risks is a business process. Risk calculations provide quantitative information that can help managers decide whether to mitigate a risk, defer it, or even accept it.

Define and Implement Security Requirements

Once a product team has prioritized the risks and defined the mitigations that will be required to combat the most pressing threats, it can begin to identify security requirements to be added to the backlog. Security requirements and controls are available from a variety of industry organizations, including:

• The Security Industry Association (SIA), specifically its IoT, Cloud and Mobility Subcommittee, which is in the process of defining recommended cybersecurity controls for connected security products
• The Cloud Security Alliance (CSA), whose “Future Proofing the Connected World” paper recommends a set of controls for secure product development
• The European Union Agency for Network and Information Security (ENISA), which has published recommendations for minimum baseline security requirements for connected systems

Product teams can review documentation from these organizations, then map applicable controls to the mitigations identified in their risk analysis. Although each security product is unique, certain security controls should be considered for every type of connected product. Table 2 provides a set of best practice security guidelines that product manufacturers should consider implementing.

Table 2: Best Practice Security Guidelines

Objective	Description
Secure the boot process	Enforce device policies that: Verify the firmware signature prior to booting Restrict standard users from making modifications to boot process options Reset the product if the boot process fails
Enable a secure onboarding process	The bootstrap process allows the user to bring the product into an operational state; products should: Provision unique default passwords for each device Incorporate hardware-based security for cryptographic key storage Optionally partner with a cloud service provider to enable zero-touch provisioning
Develop good authentication practices	Authentication weaknesses represent a common attack vector; products should: Require strong (complex) passwords Require that default passwords be changed upon first use Ideally use certificates instead of passwords for authentication Incorporate multi-factor authentication for cloud services
Manage privileges	Once an attacker gains access to a device, limit his ability to cause more damage by: Disabling the root account and requiring sudo access for all elevated privileges, Limiting the privileges associated with any particular account
Enable secure pairing	Many options exist when implementing pairing mechanisms; be sure to: Use security-enabled pairing mechanisms for all device-to-device interactions
Use good cryptographic practices	The selection of cryptographic libraries and protocols underpins the security of a product; make sure to: Use Transport Layer Security (TLS) 1.2 or above for all interfaces to the cloud Enable Secure Shell (SSH) for remote access Only use standards-based cryptographic algorithms and protocols
Enable logging	Many IoT products are shipped with limited audit and logging features; provide this basic security service to users by: Defining security-relevant events and logging them to an access-controlled file Logging security-relevant events to a remote server
Secure hardware	Firmware extraction can allow attackers to identify zero-day vulnerabilities in a product and open test ports can sometimes provide direct command line access; make sure to: Disable test ports (JTAG, UART, USB) Implement tamper resistance techniques, if needed

Test Product Security

One of the most important aspects of any cybersecurity program is testing. Comprehensive testing of connected devices allows the program team to identify design flaws, gaps in requirements coverage or handling and flaws in code. There are several types of security testing that a product team should conduct. Ideally, testing should be continuous. Test tools that look for non-adherence to coding standards and typical software development flaws should be incorporated in the continuous integration (CI) environment and run upon each check-in. These tools will alert the team and will even halt code integration upon detection of certain issues.

An equally important type of testing involves analysis of a product’s firmware. Firmware analysis allows an evaluator to perform a binary analysis on the code that runs the product. Analysis tools extract and analyze the file system to identify known malicious files. They can also run static analysis to quickly identify product vulnerabilities. This includes performing an analysis on third-party code. Firmware analysis can also prove useful from a license management perspective, as it can often provide a report detailing the third-party libraries that have been implemented and their licensing requirements.

Firmware analysis tools should be integrated into the CI environment just like other automated testing tools. This allows them to be run automatically on new versions of firmware so they can report on issues requiring remediation. New innovations in firmware analysis even report back on design flaws in a product and map back to groups of requirements from standards and best practices published by industry organizations such as SIA, ENISA, CSA, the IoT Security Foundation and others.

Brian Russell (brussell@vdoo.com) is a security adviser at VDOO, and Leo Dorrendorf (leo@vdoo.com) is a senior security architect at VDOO.

This article originally appeared in the spring 2019 edition of SIA Technology Insights.