According to current reports like in “A survey of emerging threats in cybersecurity” [1] a large number of security breaches in software systems are due to internal security vulnerabilities. These security risks usually originate in the implementation or in the third-party libraries used. The Open Web Application Security Project (OWASP) regularly publishes a list of the ten most critical security risks for web applications1 and IoT applications2. Due to the prevalence of these vulnerabilities, the high risk of their exploitation and the potentially serious consequences, performing security testing at the very beginning of software development is inevitable. To meet the ever-shorter development cycles, the IoTAC project will incorporate test and security strategies into the so called DevSecOps lifecycle, an extension of the well established DevOps lifecycle model.
Functional Testing
Within the DevOps pipeline, functional tests will be executed. Functional tests are based on the functional description of the application. The main objective is to evaluate the functionality of the application and to detect faults in their implementation at an early stage. Therefore, the application is tested for correct implementation of the functional requirements. Since requirements exist on different abstraction and software levels, functional testing also takes place on different levels. The most well-known model is the V-model, which compares the individual test levels with the development levels. For example, a unit test tests only individual components, while a system test tests the system as a whole. Since it is usually impossible to completely cover the input space of a function with a finite number of test cases, special techniques will be used to identify a suitable set of test cases [2]:
- random testing: feed the application with random values.
- equivalence partitioning: inputs are partitioned into equivalence classes, e.g. valid and invalid values, or based on semantics.
- boundary value analysis: choose values from boundaries of equivalence classes as test data.
- model-based Testing: create test model based on requirements that represents the expected behaviour which is used to generate corresponding test cases.
Security Testing
Functional tests ensure that software behaves as it should. However, not everyone who interacts with the application does so for the intended purpose. Issues related to security vulnerabilities may not be detected if only the perspective of “normal” users is taken into account. This is where security testing comes into play as it extends the DevOps lifecycle into a DevSecOps lifecycle by addressing security issues at every stage of the software development lifecycle as shown in Figure 1.
Figure 1: DecSecOps Lifecycle
In security testing, systems or applications are specifically examined for existing vulnerabilities. In addition to the (non-)functional system requirements, security testing requires the definition of security requirements. Security requirements generally originate from multiple sources: Some are already predetermined for regulatory compliance or by organizational security policies, and others result from risk analysis or consideration of security guidelines and standards like the OWASP Application Security Verification Standard (ASVS) [3].
Basically, two approaches can be used to identify security vulnerabilities: Static and Dynamic Application Security Testing (SAST/DAST). SAST is a white-box approach that analyses the source code for known vulnerabilities. This can be done during programming or in the DevSecOps pipeline. DAST is a black-box security testing approach that tests an application in its running state by executing simulated attacks to penetrate an application in order to identify vulnerabilities. This includes various techniques that can cause the application to break or reveal information that can be used by an attacker. The scope of DAST ranges from testing individual input fields (e.g., testing for SQL injection) over fuzzing (highly automated approach that generates randomly invalid and unexpected input data) up to Denial-of-Service (DoS) attacks.
In the IoTAC project we will integrate both SAST and DAST in addition to functional testing into the DevSecOps pipeline. The early execution of static and dynamic security tests helps to detect vulnerabilities at an early stage and thus, leads to a more secure system before it is deployed.
The IoTAC project aims not only to deliver a secure IoT architecture, it also establishes and provides processes for the achievement of security by design through the establishment of static and dynamic security testing across every level of the software development lifecycle through integration of automated security testing including penetration in the DevSecOps toolchain to support developers in their endeavour to develop vulnerability-free code.
1 https://owasp.org/www-project-top-ten/
2 https://owasp.org/www-pdf-archive/OWASP-IoT-Top-10-2018-final.pdf
References
[1] JANG-JACCARD, S. Nepal “A survey of emerging threats in cybersecurity” Journal of Computer and System Sciences, pp. 973-993, 2014.[2] Beizer, Software testing techniques, 2. ed., New York: Van Nostrand Reinhold, 1990, p. 550.
[3] OWASP, “Application Security Verification Standard,” 1 October 2020. [Online]. Available: https://raw.githubusercontent.com/OWASP/ASVS/v4.0.2/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.2-en.pdf. [Accessed 28 January 2021].
