A Concept for Language-Oriented Security Testing

Background: Software testing and software security have become one of the most important parts of an application. Many studies have explored each of these topics but there is a gap wherein the relation of software security and software testing in general has not been explored. Objective: This study aims to conduct a systematic literature review to capture the current state-of-the-art in software testing related to security. Methods: The search strategy obtains relevant papers from IEEE Xplore and ScienceDirect. The results of the search are filtered by applying inclusion and exclusion criteria. Results: The search results identified 50 papers. After applying the inclusion/exclusion criteria, we identified 15 primary studies that discuss software security and software testing. We found approaches, aspects, references, and domains that are used in software security and software testing. Conclusion: We found certain approach, aspect, references, and domain are used more often in software security testing Keywords: Software security, Software testing, Security testing approach, Security threats, Systematic literature review

Software security testing is an important technique for discovering software vulnerabilities that violate security requirements. Existing security testing methods, however, seldom generate security tests directly from security requirements specifications. To address this issue, this paper presents an approach for constructing security test models from the artifacts of misuse case modeling (i.e., use/misuse cases and mitigation use cases), which is a popular method for security requirements specification in the software development process. The security test models can then be used to automatically generate security tests, which consist of test inputs (normal behaviors from use cases and attack actions from misuse cases) and test oracles from mitigation use cases. We have applied the approach to two case studies. One case study demonstrates that the proposed approach can build security test models in a structured fashion such that the generated security tests are as effective as reported in the literature. The second case study applies the proposed approach to an ongoing software development project. The security tests have revealed at least 24 vulnerabilities, and are very helpful for the development team to improve the security of the software implementation. This demonstrates that the proposed approach is effective in the software development process.

Semantic web Racer: Dynamic security testing of the web application against race condition in the business layer

This study aims to analyze and improve the security of the SawitGoDigi Palm Oil Harvest Recording Information System using grey-box and white-box testing approaches. The system is used by farmers, agents, drivers, and administrators to manage land data, harvest results, distribution, and transaction records, which makes it highly exposed to security risks if vulnerabilities are present. The security testing process was conducted based on the OWASP Web Security Testing Guide (WSTG) v4.2 and the OWASP Risk Rating Methodology. The testing stages included reconnaissance, automated scanning using OWASP ZAP, manual exploitation, risk evaluation, implementation of security improvements, and retesting. The results revealed several significant vulnerabilities, including SQL Injection in the search feature, weak session management through the trusted_device cookie, and the absence of a rate-limiting mechanism that enabled brute-force attacks during the login process. The risk assessment indicated that SQL Injection and session hijacking were classified as High risk, while brute-force attacks were categorized as Medium risk. Security improvements were implemented through the use of prepared statements, strengthening cookie attributes, adding security headers, and implementing rate limiting. Retesting results confirmed that all identified vulnerabilities were successfully mitigated and reduced to a Low-risk level. This study demonstrates that a comprehensive security testing approach, which includes exploitation, remediation, and verification through retesting, can significantly enhance the security of agribusiness web applications. Furthermore, the findings show that before remediation, the system contained four vulnerabilities with High and Medium risk levels, namely SQL Injection, Session Hijacking, Brute-Force Login, and Security Misconfiguration. After the remediation and retesting process, all High- and Medium-risk vulnerabilities were successfully reduced to Low risk or marked as Closed, indicating that the system is secure for operational use.

Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners’ trust in them may decrease, leading to inefficiencies in task execution. This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts. We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention. Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact. Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.

While aerospace launch vehicles are vulnerable to security attacks, post-liftoff attacks have the most potential for destruction including loss of the vehicle or loss of life. This paper demonstrates an approach for security testing an aerospace launch system post-liftoff. This approach is based on building a security test suite from a behavioral model, an attack type and a mitigation model. Our behavioral and attack models are used to determine attack points in a system. We can then build a security test suite based on attack mitigation models.

Security testing can broadly be described as (1) the testing of security requirements that concerns confidentiality, integrity, availability, authentication, authorization, nonrepudiation and (2) the testing of the software to validate how much it can withstand an attack. Agile testing involves immediately integrating changes into the main system, continuously testing all changes and updating test cases to be able to run a regression test at any time to verify that changes have not broken existing functionality. Software companies have a challenge to systematically apply security testing in their processes nowadays. There is a lack of guidelines in practice as well as empirical studies in real-world projects on agile security testing; industry in general needs a more systematic approach to security. The findings of this research are not surprising, but at the same time are alarming. The lack of knowledge on security by agile teams in general, the large dependency on incidental pen-testers, and the ignorance in static testing for security are indicators that security testing is highly under addressed and that more efforts should be addressed to security testing in agile teams.

Edge computing is a distributed computing paradigm aiming at ensuring low latency in modern data intensive applications (e.g., video streaming and IoT). It consists of deploying computation and storage nodes close to the end-users. Unfortunately, being distributed and close to end-users, Edge systems have a wider attack surface (e.g., they may be physically reachable) and are more complex to update than other types of systems (e.g., Cloud systems) thus requiring thorough security testing activities, possibly tailored to be cost-effective. To support the development of effective and automated Edge security testing solutions, we conducted an empirical study of vulnerabilities affecting Edge frameworks. The study is driven by eight research questions that aim to determine what test triggers, test harnesses, test oracles, and input types should be considered when defining new security testing approaches dedicated to Edge systems. preconditions and inputs leading to a successful exploit, the security properties being violated, the most frequent vulnerability types, the software behaviours and developer mistakes associated to these vulnerabilities, and the severity of Edge vulnerabilities. We have inspected 147 vulnerabilities of four popular Edge frameworks. Our findings indicate that vulnerabilities slip through the testing process because of the complexity of the Edge features. Indeed, they can’t be exhaustively tested in-house because of the large number of combinations of inputs, outputs, and interfaces to be tested. Since we observed that most of the vulnerabilities do not affect the system integrity and, further, only one action (e.g., requesting a URL) is sufficient to exploit a vulnerability

Modern connected cars are exposed to various cybersecurity threats due to the sophisticated computing and connectivity technologies they host for providing enhanced user experience for their occupants by offering numerous innovative applications. While prior studies exist that explore cybersecurity challenges, tools and techniques for automotive systems, over-the-air (OTA) software updates for automobiles can be exploited by the attackers to compromise vehicle security and safety has not been covered extensively. This paper presents our Model-Based Security Testing (MBST) approach, designed for cybersecurity evaluation of the OTA update system for automobiles, which has an integrated testbed and a software tool that is capable of automatically generating and executing test cases by using attack trees as an input. Integrating threat modelling in the testing provides several benefits, including clear and systematic identification of different threats. Automation of the test-case generation and execution has the obvious benefits of saving time and manual effort, as manual test-case generation is both a time-consuming and error-prone process (especially, when the testing involves several test-cases). A simple simulated attack is used to demonstrate the validity and effectiveness of our testing approach. To the best of our knowledge, there is no prior research that uses a testing approach similar to our approach for automotive OTA security evaluation.

Early identification of defects and prevention of defects migration are key goals of the software security testing process. Early integration of security testing activities into the development lifecycle leads to secure software development. The prescribed key activities of security testing are closely interconnected with security development life cycle to deliver secure software. Software test process elaborates various testing activities and describes which activity is to be carried out when. Given the need and significance of phased approach of security testing, this paper proposes different testing activities to be carried out while integrating it within the security development life cycle.

Given the wide distribution of software and its current growth, security is inevitable, and software systems have become more complex. To avoid the complexity and protect valuable assets of software systems, researchers, and practitioners in the fields of security requirement engineering (SRE) and security assurance advise incorporating security requirements early in software development life cycle (SDLC). Nowadays, security requirements specification and identification are an active research area for ensuring the effectiveness of software systems. However, security requirement identification is a challenging task due to sheer numbers of threats and attacks to a software system. Previous researchers have identified different SRE techniques, each looking at the same problem from a different perspective. Therefore, a literature review conducted on SRE techniques. We compared and analyzed different SRE techniques to find the most suitable SRE techniques for researchers and practitioners. Selected SRE techniques compared based on various parameters, such as different attributes, requirement elicitation, requirement analysis, project size, and integration of standards. The literature also indicates that among SRE approaches, security quality requirements engineering (SQAURE), secure tropos, security requirements engineering process (SREP), and comprehensive lightweight application security process (CLASP) are the most used SRE approaches that focus on activities such as threats, security requirements identification, and security objectives identification. Unfortunately, several SRE approaches fail to explicitly integrate the security standard and security assurance perspective. Three questions developed for this study: Question 1 is based on comparison of existing SRE approaches, Question 2 is based on SRE with security requirements elicitation and analysis, and Question 3 highlights the incorporation of security requirements assurance by SRE approaches implicitly or explicitly. The researcher must work with the developer to easily adopt SRE approaches to elicit and ensure security requirements for the software system.

Energy efficiency and low carbon enabler green IT framework for data centers considering green metrics

Specification and traceability of security requirements is still a challenge since modeling and analysis of security aspects of systems require additional efforts at the very beginning of software development. The topological functioning model is a formal mathematical model that can be used as a reference model for functional and non-functional requirements of the system. It can also serve as a reference model for security requirements. The purpose of this study is to determine the approach to how security requirements can be specified and traced using the topological functioning model. This article demonstrates the suggested approach and explains its potential benefits and limitations.

Information security is a critical issue in the context of complex and interconnected nowadays IT Systems. Innovative testing approaches are demanded to verify whether the main security characteristics are provided in the systems. The conceptual formalization level required by security test processes can be supplied by semantic technologies. STEP-ONE is the Security TEst Process supported by ONtology Environment; its foundations come from largely accepted testing processes and security testing standards. The STPO (Security Testing Process Ontology) formalizes and makes explicit the main concepts of the domain. We present a conceptual characterization of STEP-ONE and describe a usage scenario to illustrate how the proposal can be applied. The main contributions are the conceptual process and the ontology. Our proposal is meant to be applied for the evaluation of IT systems with respect to security characteristics as well as to make systematic the security testing activities.

Modeling Security and Privacy Requirements: a Use Case-Driven Approach