Cybersecurity Part 3: Do we find cybersecurity testing?

In the third part of our cybersecurity blog series, we look at security testing, what it actually entails and at which part of the development lifecycle it should be applied. In the first two parts of this series we covered threat analysis and the role of dataflow diagrams, topics for the left-side of a V-model. The relationship between threat modelling and security testing is a key one in the world of cybersecurity. Let’s look further at this topic.

Searching for the holy grail…

Unfortunately, there is little guidance given in the regulatory sources for the medical (AAMI TIR 57, FDA Threat Modelling Playbook, IEC 81001-5-1) or automotive (ISO SAE 21434) industries that define a strategy for security testing. The sources that tend to shed more light on this topic are, not surprisingly, cybersecurity rather than industry specific standards or guidance documents e.g. OWASP, NIST etc.

One challenge is separating out the activities on the left and right side of the V-model. Fig. 1 shows a typical software V-model and levels at which activities are carried out.

Cybersecurity Strategies

Black and white boxes

This brings two key terms into consideration when looking at security tests, namely static application security testing (SAST) and dynamic application security testing (DAST), the former being a white box approach i.e. the internals of the code are known, the latter – the code details are unknown, however all interfaces to the software can be exercised.

The stage of the lifecycle plays its part: SAST requires source code hence used in an earlier stage in the lifecycle on the right-side of the V-model and DAST, requiring a running application, hence later in proceedings.

Fuzz Testing

Fuzz testing (or fuzzing) is the process of injecting invalid or erroneous inputs to a system to reveal defects or vulnerabilities. Fuzzing may lend itself to an exploratory approach with a black box testing methodology i.e. DAST.

Penetration Testing

Penetration testing (or pen tests) on the other hand may follow a white box approach i.e. the testers know the internals of the code and can base tests on that knowledge. Pen testing requires individuals with an extensive security knowledge and tests tend to be more of a manual process.

One of the main attractions of pen tests is that they can be subcontracted, and this can have two advantages: an independent person verifying security and the potential paralleling of activities so reducing the time to market.

Take a closer look at cybersecurity testing strategies in our Automotive Cybersecurity or Medical Device Cybersecurity course. Schedule your next training with us or send a direct inquiry at info@lorit-consultancy.com.

Learn more

Back to Vulnerability Analysis

However, some common coding vulnerabilities, such as memory corruption flaws, are hard to detect with pen tests but are relatively easily to prevent with secure architecture and appropriate coding practices.

The best strategy is a robust vulnerability analysis then followed by the planned testing strategy. The solution to identify potential vulnerabilities is dependent on a number of factors. And as with all activities in safety-related industries, planning the strategy is key to a successful process. Depending on the product and the architecture, different approaches may be scoped out.

As shown in fig. 2 there are points then in the V-model that lend themselves better to specific security activities. As with many other processes in the lifecycle, good analysis on the left side of the V-model brings an early and import iterative (evolutionary) strategy to refine and improve requirements. This is no different in the world of security to that of human factors or safety analysis.

Cybersecurity Testing: when and how frequently

One key challenge is to know how often to repeat pen tests or fuzzing. Based on threat analysis activities which may follow changes in 3^rd party software, or information that may have come to light based on cybersecurity databases, the decision may be to repeat e.g. pen testing. This then brings the need for in-house penetration testing rather than relying on external test bodies, however, a combination of the two can help catch items that may have been missed by the in-house team.

Ultimately, a topic well-known in the medical device sector, activities don’t stop once the product is launched, and this is a key consideration in the world of cybersecurity. When and how often the security landscape is monitored is down to each organization and technology in the product, but this should be a regular activity to avoid leaving vulnerabilities in the device.

Summary

There are many considerations in respect to security that make the activity more challenging than other aspects of safe and compliant product design. The analysis of vulnerabilities is similar to risk activities in other industry sectors; however, the different security test strategies require an appropriate planning and definition based on the technology and potential assets in the product.

Threat analysis should undoubtably be the key strategy, but testing plays a crucial role as we as human beings will not catch all vulnerabilities during analysis activities.

By Alastair Walker, Owner / Consultant