Building and ensuring security for your IoT device

Article By : Ricardo Camacho

All the security measures designed to enforce encryption, authentication, and protection aren't enough if the asset isn't developed securely at every phase of its software development lifecycle.

Many organizations in various industries have leveraged IP and common OS platforms that enable them to utilize libraries and network their devices quickly and easily. However, concerns around security have been poorly addressed, partly due to a lack of stakeholder or regulatory push. This is starting to change. One example is the United Nations Economic Commission for Europe’s cybersecurity regulatory requirements on the automotive industry. From a technical perspective, security, and risk management for the IoT starts at the top of the software development lifecycle (SDLC). Nevertheless, a culture of cybersecurity within the organization is just as crucial and needs to be fostered much like it has been for development of safety-critical systems.

I’m going to communicate the importance of addressing security for your IoT device starting from the requirements management phase and elaborate on the threat analysis and risk assessment activities. I’ll explain when to start building and ensuring security and where in the SDLC it is the easiest and least expensive to deal with security. I’ll then describe the verification and validation methods on detecting security vulnerabilities. It’s not enough in IoT software to look for uninitialized or corrupted data, buffer overflows, or dangling pointers. Lastly, I’ll cover additional automated test methods and practices to help secure your Internet of things (IoT) connected device.

IoT security landscape

With the enormous proliferation of devices on the IoT, security has become a primary concern across nearly every vertical market segment. Industrial control equipment, automobiles, and medical devices can all be remotely monitored or controlled. Though this wireless connectivity provides high-value capabilities, it introduces gaps in security and opportunities for malicious activities.

The impact of having their data hacked or held for ransom can be devastating for both the user and the manufacturer, but all the security measures designed to enforce encryption, authentication, and protection aren’t enough if the asset isn’t developed securely at every phase of its SDLC, starting from inception to maintenance and final retirement. Putting things in more concrete terms, start by considering all security regulatory requirements, including customer security requirements and security quality of service requirements. Then propagate them throughout the systems engineering development phases: Requirements management and decomposition, which help drive the architectural design, implementation, and testing. But testing is not much more complicated than what it used to be.

What brings complexity to ensuring security through testing is not just the connectivity to other devices, as shown in Figure 1, but also the interaction with additional related technologies. For example, is your operating system security hardened? Is your boot image securely verified? Are all your assets’ entry and exit endpoints secure? These questions make you ponder—how in the heck do we secure the IoT?

click for full size image

Fig. 1. IEC/TS 62443 example of a graphically rich logical network diagram.

It is important that the organization has a clear understanding of the boundaries of the system to be assessed for security. The scope goes beyond existing functional requirements. Securing the IoT device includes validating user access through enforced classes of user privileges; preventing hardware and software changes to the device to ward off any bypassing of safety and security functionality; and ensuring data is protected from online and offline access and not just by way of Wi-Fi but keeping data transfer secure through all possible channels (Bluetooth, USB, etc.).

The Gartner management consulting company has put out some cybersecurity predictions centered on this distributed ecosystem. Boards of companies realize that cybersecurity is not just a technical risk but a business one.

Gartner predicts:

• By 2026, at least 50% of C-Level executives will have performance requirements related to cybersecurity risk built into their employment contracts.
• By 2025, 60% of organizations will use cybersecurity risk as a significant determinant in conducting third-party transactions and business engagements.
• By 2025, 50% of cybersecurity leaders will have tried, unsuccessfully, to use cybersecurity risk quantification to drive enterprise decision making.
• By 2026, 30% of large organizations will have publicly shared environmental, social, and governance (ESG) goals focused on cybersecurity, up from less than 2% in 2021.
• By 2025, 40% of programs will deploy socio-behavioral principles (such as nudge techniques) to influence security culture across the organization, up from less than 5% in 2021.

Security regulations and standards for IoT

To get started on the right track to security, it is vital to be aware of all laws and regulations that are in effect and geography makes a big difference. For example, in 2017 California became the first state in the United States to adopt an IoT specific cybersecurity law (California Civil Code § 1798.91.04), which requires manufacturers of IoT devices to equip any IoT device manufactured with a “reasonable security” feature or features. This includes security requirements to protect the device and any information contained on the device from unauthorized access, destruction, use, modification, or disclosure. Other states are now following.

Another example is the European Union’s rules on data protection and privacy, General Data Protection Regulation (GDPR). Many IoTs operate using the same personal data such as email address, IP address, phone number, and other private data, so GDPR applies. Therefore, IoT assets must ensure they have full visibility into their network endpoints and even customer consent to fully protect customer identifiable information from data breaches.

There are also several standards in support of security, such as IEC 62443: Security for Industrial Automation and Control Systems (IACS). This standard aims to mitigate risks for industrial communication networks by defining procedures for the secure development of software for IACS. However, ensuring security is an evolving endeavor that goes beyond the mere technical engineering and process standards like IEC 62443. Companies also need to incorporate organizational changes that foster its people, processes, and technologies working together in ensuring security. Standards like ISO 27001 provide the framework for employing an information security management system (ISMS), which helps organizations manage their security practices consistently and cost-effectively. Some of ISO 27001 best practices include having a security staff awareness program, procedures for monitoring threats, encryption, incident management process and much more. Also, though not mandatory, obtaining certification to ISO 21001 lets your business prospects and existing customers know of your organization’s willingness to satisfy internationally accepted security standards.

The security lifecycle and testing

Adopting and incorporating security is not as difficult as it may seem. Organizations that build embedded devices are very familiar with functional safety standard IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems. The safety software lifecycle defined in IEC 61508 overlaps with much of IEC 62443-4-1: Secure Product Development Lifecycle Requirements.

Heavy collaboration between your security and safety teams is required, including the use of a solid product or application lifecycle management (ALM) tool. Just as safety requirements are captured in ALM tools by system engineers to later perform requirements management, the security team must do the same. Security requirements for the system must be captured and be well defined. Allocation of security requirements to the various technical domains (software, hardware, mechanical, electrical, etc.) should also be made. The security requirements should be further decomposed and traced back to the higher-level security requirements to ensure that there are no security gaps in the design. In fact, the process lifecycles between safety and security are so similar that they can be overlapped and presented in the well-known V-model process lifecycle.

click for full size image

Fig. 2. Overlapping Security & Safety Development Lifecycles

System-level security requirements must also have system-level test cases created. Security engineers defining and decomposing requirements are the ones best suited to define test cases that ensure the correct security functionality is achieved. Security-system-level test cases are defined through descriptive text with specific input and output criteria. Later, the quality assurance (QA) team will realize each test case and validate the security requirements that it traces back to. It’s important to understand the levels of abstraction to security requirements and, in turn, the levels of abstraction to security testing. DAST type of testing at this level includes test methods like penetration testing, API testing, service virtualization, security functional testing, fuzz testing, UI testing, and test case code coverage.

click for full size image

Fig. 3. System Level Requirements Testing

Moving down the left side of the V-model, system-level security requirements are decomposed and become infused into the architectural high-level design of the system. High-level security requirement test cases are also defined. These test cases commonly test the interaction between component, subsystems, and/or functional capabilities. These types of DAST test cases are better known as integration test cases. At this level in the lifecycle, they commonly include test methods like API testing, service virtualization, security functional testing, and fuzz testing.

click for full size image

Fig. 4. High Level Requirements Integration Testing

The next level of security requirements decomposition addresses detail design. Functional units of code are to be built-in support of security functionality. These requirements link back up to its parent requirement and the unit-level test cases created by the security system engineer to be realized by the software engineer. In turn, the software engineer could link the code written that implements the requirement to the requirement artifact. This level of traceability provides a lot of value if you have an ever-evolving set of changing requirements. For example, if a requirement is eliminated or determined for a future release, having traceability directly to the exact code that implements the requirement makes it a seamless effort with minimal to no ill effects when removing the code. Though more energy is put into traceability, the payback is substantial when requirements are ever changing. And if an engineer makes changes to the code, traceability will point to the requirements that it may impact.

click for full size image

Fig. 5. Low Level Requirements Unit Testing

The software engineer must also construct various unit test cases to not just validate the requirement and functional capabilities that it implements, but also that the code is robust enough to support as many threat scenarios as possible. For example, test cases that invoke set and get functions can check for request validity when data is asked for or provided. Encrypting the data should be considered at a minimum. Other types of test methods at the unit level could include fuzzing, which could expose a vulnerability.

At the bottom of the V-model is where security implementation takes place. The engineer is coding to requirements. For IoT devices C and C++ is commonly used. These languages have coding constructs that should not be used. For example, a lot of C vulnerabilities relate to buffer overflows. Buffers are areas of memory set aside to hold data. Vulnerable code may be written, which allows an exploit to write over other important values in memory, like the instructions of what to execute next for the CPU. C and C++ are susceptible to buffer overflows because they define strings as null-terminated arrays of characters, do not implicitly check bounds, and provide standard library calls for strings that do not enforce bounds checking. Here at the core level of development, security coding analysis solutions exist to mitigate these security issues.

click for full size image

Fig. 6. Static Analysis Security Testing

SAST should be your first level of testing against security vulnerabilities. There are coding standards like SEI CERT, CWE, and others like MISRA C:2012 and AUTOSAR C++14 that can be applied on the code for analysis. Coding security violations will be exposed for quick remediation. Static analysis tools like Parasoft C/C++test integrate into your favorite IDE and its static analysis solution can also integrate into your DevOps pipeline so that security is built right into your organization’s build process. Code quality, lower costs in testing, and an increase in time to market have been reported by many organizations that have incorporated Agile methodologies like Scrum and DevOps CI/CD.

Having stepped through the development lifecycle should give readers a perspective of the different levels within product development in which employing security measures is required. Now stepping back and looking at the big picture, where the IoT is part of a rich network, testing that addresses its connectivity in the larger scope or context it lives in needs to be made. This type of testing can be a combination of SAST and DAST.

Threat analysis and risk assessment

To determine how best to protect against cybersecurity threats, organizations need to perform a threat analysis and risk assessment (TARA). This can be somewhat complicated as there are many cybersecurity risk assessment approaches and frameworks that are under deployment. Some come from government and others come from commercial organizations (e.g., NIST, ISO, OCTAVE, NCSA, etc.).

At the core of this topic sits several risk categories. Ethics is one of them. Is a company willing to be unethical with their IoT device for the purpose of bypassing regulatory mandates or gaining an advantage? There is also the more sinister risk scenario where a player searches for a way to gain access to assets with intent of causing harm. And there is also the technical risk that software and/or hardware vulnerabilities exist in the IoT design.

These risk factors have a threat likelihood ranking that is commonly labeled as high, medium, or low. Along with the threat, what is the impact if the threat goes live? Impact can be categorized as severe, elevated, or low. The following formula exists for calculating risk ranking.

Risk Ranking = impact (if exploited) x likelihood (of exploit)

Risk rank calculations can be further expanded upon by assigning a qualitative level through incorporating quantitative weightage measures.

Some organizations have further defined cybersecurity assurance level (CAL), respective to quantitative levels shown in table I. For example, CAL 4 equates to “very high” risk, requiring the most stringent process for ensuring security. CAL 0 equates to virtually no risk.

Table 1. Risk rank calculations

IEC 62443 defines security levels (SLs 0-4)

• SL 0: No specific requirements or security protection necessary
• SL 1: Protection against casual or coincidental violation
• SL 2: Protection against intentional violation using simple means with low resources, generic skills, and low motivation
• SL 3: Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills, and moderate motivation
• SL 4: Protection against intentional violation using sophisticated means with extended resources, IACS specific skills, and high motivation

So, what does this mean regarding software security development?

The different SLs express different levels of effort or rigor that needs to be applied to the development and testing of the software. For example, Annex B in IEC 62443-3-3 captures security requirements or capabilities that need to be fulfilled based on the SL value. Additionally, each requirement or capability that is implemented needs to be thoroughly verified and validated. Test methods (pen testing, API testing, SAST, etc.) depend on the capability/requirement that has been implemented. Table II shows a small sample mapping list of security requirements and requirement enhancement to SLs.

Table II. Sample Mapping of SRs and REs to FR SL levels 1-4

Conclusion

The world of IoT continues to grow at a rapid pace with more and more security accountability shifting to businesses. Organizations need to continue to adopt standards like IEC 62443 to fulfill their security technical needs and ISO 27001 for their business and organizational security preparedness.

Subscribe to Newsletter