THE EMBEDDED ANTHOLOGY PART XI – Securing IoT Systems End to End

It goes without saying that security is a product differentiator in terms of reputation & brand image. In other words, a trusted product with superior security will have a competitive advantage over its competitors.

In order to illustrate the prevalence of IoT devices as a target for cyber-attacks, research from the cybersecurity at Kaspersky has found that attacks targeting IoT devices have doubled over the past year. The rapid proliferation of IoT devices, combined with often poor security, makes them an increasingly attractive target for hackers.

For quite a while, Witekio has been guiding its customers in the jungle of IoT security standards and frameworks. Here is a webinar on the subject.

SECURITY NEEDS IMPERATIVES are multiple and range from data exposure, physical damage, and service failure (DOS attack) to the most critical one, namely its impact on reputation and brand image.

In addition to all that, the regulatory requirements oblige many device makers to adopt proper development methodology (secure development lifecycle), whereby the security requirements are to be defined from day one!

As for the IoT security standards and frameworks, despite the lack of universal standards, there is a trend towards defragmentation of the latter. Examples of this are EU’s Cybersecurity Act, UK’s PTSI Bill, etc.

SECURITY BY DESIGN (SBD) in a nutshell is about the fact that security cannot be added to a product after it has been created. SBD is about including security throughout a system at all levels, i.e., not only within the end-product but also in the development process used to create the latter.

Unlike the common belief, security in a product is not one man’s responsibility and it is everybody’s business, i.e., all those involved in the product development process. To induce a security mindset in the product team, we need to educate them.

RISK MANAGEMENT consists of understanding the threats, their likelihood of happening, and their impact in terms of lost revenue and damage to the brand image. The next step would be to rank/score the risk and define mitigation strategies to address the latter.

It is also of great importance to pay attention to the dynamic nature of risk as it evolves during the development process due to factors such as requirements shift and design & staff changes. Hence, the need for tracking and revision of risks during regular risk analysis sessions.

REQUIREMENTS PHASE is where the risk analysis begins, i.e., once the initial product requirements have been defined and it consists of understanding how critical security is for the product; in which environment it will operate; who will have access to it; and last but not least the privacy / data protection requirements.???

DESIGN PHASE being quite critical requires an architectural risk analysis which is about reviewing the proposed/created architecture via design diagrams and artifacts. This allows identifying the “attack surface” of the system, i.e., components exposure: to users (including employee/admin ones); to other hosts on networks/Internet, as well as unknown peripherals. Once this is done, the next logical step would be to define security tests. The security tests must be added to the existing (default) test plan. As for which one to focus on, the risk score should be the guideline, i.e., focus on the highest-ranking risks.??

IMPLEMENTATION PHASE is to be launched once approved tools have been defined and put in place, i.e., code generators, compilers, libraries, and anything that could have an impact on the final production firmware image. As for code-review, it is to be noted that tools only recognize complex “patterns” which cause vulnerabilities, so for architectural flaws you need human eyes!

TEST PHASE is mainly about re-evaluating the implementation against the security design analysis, followed by “Fuzz & Penetration Testing”. As for the former, this re-evaluation of the implementation against the initial security analysis is justified by the fact that designs tend to change as a developer starts typing. However, ideally the deviations are caught in manual code-reviews or when tracking mitigations in periodic risk management reviews.

As for Penetration & Fuzz Testing, considering the fact that it is quite unusual to find software developers well-practiced at breaking into systems, it is often outsourced to external specialists. Fuzz Testing consists of injecting invalid, malformed, or unexpected inputs into a system to reveal software defects and vulnerabilities.

Penetration Testing is usually done when the product is ready to use, and it is not an automatic scan, but rather about skilled hackers assessing your solution and its design. From HW to SW, it is about finding and exploiting vulnerabilities from different perspectives, i.e., remote, or local attacker and outsider or insider. Pen-Tests are divided into three categories, namely Black-, Grey- and White-Box tests. A Black Box scenario simulates outsiders without information, which often reveals the weakest links but is not exhaustive enough.

A Grey Box test simulates attackers with some kind of privileges which detects security issues on authenticated services. It is therefore suitable when you do not trust your users, being malicious users or compromised user accounts.

And last but not least, a White Box attacker has access to the source code and documentation and is suitable when your code is open-source or can be bought or as a complementary test on top of an already performed a black or grey box test. It is strongly advised to do the penetration testing much earlier in the process, because it would be more expensive if you find a design issue after the implementation started. To avoid this risk, it is recommended to do an audit after each development feature /cycle followed by a final audit at the end of the development process.

RELEASE & FEEDBACK PHASE begins with an “Incident Response Plan” followed by “Release Archiving”. The former aims at ensuring that the required actions are known ahead of any vulnerability disclosure. Add to that the necessity of providing a public contact address for customers / end users to report vulnerability which is required by most security standards.

As for Release Archiving, it is essential for the long-term support of a release and for preparing for future maintenance. The extent of this archiving effort is normally established in the initial risk assessment. It basically consists of archiving all project documentation up to the build tools and environments to run them and debug symbol files for binaries in production firmware images.

CONTINUAL PROCESS UPDATES are required due to the fact that security is a moving target and, hence, requires continuous re-adjustments. In case a vulnerability makes it into a release, one must try to understand what went wrong and how that vulnerability was missed. Once this root cause analysis is done, the secure development process needs to be modified in order to avoid the chance of a similar vulnerability slipping through again.

It might sound like a lot of effort, but it goes without saying that fixing issues earlier significantly reduces the cost and security in this respect is no different. You might also be thinking “why not just rely on a certification standard / framework to guide me?” The fact is that framework guidance is less clear than if you learn what you need to do ahead of time; it can easily turn into a ticking exercise; and could even make your team resentful of certification audits as a time drain.

If you want to learn more on Witekio ’s security offerings you know where to find me ??

Embeddedly yours,

Cirus Coliai (BDM at Witekio for France, UK & Northern Europe)

#embeddedsoftware #IoTsoftware #softwaredevelopmentcompany