Head – to-head Penetration Testing vs. Vulnerability Scan Security Testing for Embedded Systems
In the area of embedded systems, security by design and secure software outstaffing development are of particular importance. This requires security testing throughout the entire life cycle, this article is dedicated to pen testing on the one hand and vulnerability scans on the other.
Companies on the topic
In the area of embedded software engineering, testing for vulnerabilities is a very special challenge.
If you want to bring embedded devices with an appropriate level of security to the market, as a provider you can’t help but integrate a security check into the software development process. Ideally, this means incorporating security considerations into all phases of the life cycle of an embedded device.
This applies from the initial product architecture and product design through implementation and testing to use and monitoring in actual use. And all the way back to design – at least if you want to take into account the constantly changing threat landscape as well as the market requirements and all the problems that occur with the real use of the devices.
At this point, we focus on the actual testing phase within the safety process. Similar to the testing phase within the development process, where the functional implementation is checked, this part ensures that safety functions have been correctly implemented.
This includes finding known vulnerabilities as well as checking their usability, identifying potential security vulnerabilities and the overall picture of a product’s security profile. This affects both the product as a whole and the individual components. Regardless of whether these components were developed entirely in-house, created using open source code or sourced from third parties.
The same obligations apply regardless of whether you are the supplier who has brought a particular product to market, an integrator for the product or an OEM supplier or service provider who uses a standard product under your own brand name. If security problems occur with a networked product, then all the parties mentioned are liable.
For those who just want to buy an Internet-enabled product, it is not easy to assess how safe (or less secure) it actually is. Manufacturer statements alone are not always helpful at this point. Less well-known manufacturers in particular tend to overestimate the safety of their products. But even established providers are far from infallible.
Experts regularly find serious security problems in well-known products (D-Link, Linksys, Android and MikroTik, to name a few). A process that assesses the safety status of a product and provides concrete evidence that verifies and substantiates (or refutes) a manufacturer’s safety information helps all parties involved.
Different paths lead to the goal. Traditional approaches rely on internal quality assurance during the development and verification phase and have penetration tests and certifications carried out by independent external organizations. Newer approaches, on the other hand, focus on automated tests and vulnerability scans. Each of these methods has its advantages and disadvantages. But if you want to solve all relevant problems, you can’t help but combine some or all methods.
Quality assurance for safety functions
Quality assurance (QA) is a phase established in the development process, which is usually supervised by an internal team. Depending on the respective organisational structure, those responsible for quality assurance are themselves part of the development team or a separate team. If necessary, even under separate management, which ensures a certain degree of independence.
How a QS team is structured has a direct impact on its approach, how it is influenced by input from the developers, and last but not least, which tests are carried out in practice. When testing, a good QA team takes an approach that matches that of the potential opponent. For example, an attempt is made to crack the product code or cause it to fail (negative tests). An approach very similar to that of potential attackers or pen testers.
However, QA teams test far more frequently whether the product code fulfils the desired function as expected (positive tests). To give an example: when testing a software update mechanism, positive tests check how robust the code is and whether it correctly applies valid updates. Negative tests, on the other hand, check whether it is invalid update content, incorrect signatures or invalid certificate chains.
These negative cases are the ones that appear with a higher probability in an attack scenario. In this example, it is much easier to list the positive tests exhaustively, rather than all the negative marginal cases. They easily fill a whole page, if you want to go into all possibilities, such as how a certificate check can fail.
For similar reasons, QA teams tend to focus on the positive tests in case of heavy workload or overload (the usual situation). Because they are absolutely necessary to bring a product to the market. Conversely, this often leads to the fact that QS does not require negative tests. And exactly those are required to check how safe a product is.
In order to properly perform security functions, QA teams need dedicated resources and should be sufficiently specialized in security. Either way, you should not refrain from regularly involving other security experts in the company. You should lead the QS team and work on the test plan.
The main difficulty lies in the fact that this process is resource-intensive and depends on the (necessary!) Concentration of QA on functional tests distracts. This is why many companies are reluctant to free up the necessary QA resources for secure, Internet-enabled products. Instead, most opt for external penetration testing to determine a product’s security status.
Content of the article:
- Page 1:
Security Testing for Embedded Systems
- Page 2:
Penetration tests for deep analysis (Deep Analysis)
- Page 3:
Automated vulnerability scans for objective results
& gt; Next page