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
