Software Security Testing via Misuse Case Modeling

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 applications are essential for managing daily life activities, including social interactions and business transactions, that significantly increase the need for security in sharing sensitive information. Misuse case modeling is used for identifying and analyzing security requirements in software applications. However, security threats and their corresponding mitigations are inherently cross-cutting concerns. These concerns are scattered and tangled within multiple functional requirements and cannot be modularized using traditional object-oriented techniques. The realization of misuse cases causes crosscutting threats and corresponding mitigations to be scattered and tangled across use cases, resulting in ambiguity, incomplete understanding, and insufficient analysis of security requirements. This study proposes a misuse case modelling method called Aspect-oriented Formalized Misuse Case (AFMUC). It specifies crosscutting security threats separately as an aspect misuse case and integrates them with use cases using an aspect-oriented approach. AFMUC provides structured guidelines and restriction rules for modeling crosscutting security threats and corresponding mitigations using aspect-oriented constructs such as Pointcut, Joinpoint Advice, and Introduction. The aspect threat model is then woven into the base use case model. Similarly, an aspect mitigation model is proposed to specify crosscutting mitigations following the AFMUC restriction rules. The aspect mitigation model is then woven into the base misuse case model. The proposed approach is applied to a case study and evaluated through a controlled experiment involving twenty-four students with a background in information security. The findings indicate that the AFMUC approach is practical and unambiguous for specifying and analyzing crosscutting security requirements. However, some aspect-oriented modeling constructs and restriction rules have been misapplied by students. This shows that while students favored the AFMUC approach, they may have found it challenging to apply the aspect-oriented constructs and restriction rules due to a limited exposure to aspect-oriented modelling.

Today's ongoing trend towards intense usage of web service based applications in daily business and everybody's daily life poses new challenges for security testing. Additionally, such applications mostly not execute in their own runtime environment but instead are deployed in some data center, run alongside multiple other applications, and serve different purposes for sundry user domains with diverging security requirements. As a consequence, security testing also has to adapt to be able to meet the necessary requirements for each application in its domain and its specific security requirements. In addition, security testing needs to be feasible for both service providers and consumers. In our paper we identify drawbacks of existing security testing approaches and provide directions for meeting emerging challenges in future security testing approaches. We also introduce and describe the idea of language-oriented security testing, a novel testing approach building upon domain-specific languages and domain knowledge to meet future requirements in security testing.

Towards developing consistent misuse case models

A scientific evaluation of the misuse case diagrams visual syntax

Software security testing tools and methodologies are presently abundant, and the question no longer seems to be "if to test" for security, but rather "where and when to test" and "then what?". In this paper we present a review of security testing literature, and propose a software security testing scheme that exploits an intra-organisational reposi- tory of discovered vulnerabilities that closes the loop after the testing of one application is complete, providing useful input to the next application to be tested.

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

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

Nowadays, it is impossible to ignore the implementation of security features in information systems since they manage important assets that are critical for the business processes of organizations. In this aspect, there have been several researches for introducing the security analysis in different stages of software development life cycle. Among those solutions, one of the most interesting one is the usage of misuse cases. Misuse cases, which are extensions of the well-known use cases, were created for defining security requirements. A misuse case can be considered as the inverse of a use case and it defines functions that the system should not allow. Even though, misuse cases are very useful for eliciting security requirements, they do not provide a mechanism to prioritize such requirements. Therefore, they do not address the problem of optimal risk management. Software engineers often have to work within a given set of budget constraints that may impede them from implementing all possible countermeasures. Thus, the software engineer needs to find a way to prioritize the security requirements to decide which requirements will be developed. Motivated by the mentioned limitation of misuse cases, the presented paper proposes an enhanced misuse case model which incorporates a method for prioritization of security requirements.

The rapid pace of software development and deployment in today's digital world demands an integrated approach to security, particularly in Continuous Integration/Continuous Deployment (CI/CD) pipelines. Traditional approaches to security, where it is added at the end of the development lifecycle, have proven inadequate in addressing the complexities and vulnerabilities introduced by fast-moving development cycles. DevSecOps (Development, Security, and Operations) represents an evolution of the DevOps culture that integrates security as an essential component throughout the development process, rather than as an afterthought. This paper explores the role of DevSecOps in ensuring continuous security integration within CI/CD pipelines, focusing on its principles, practices, and impact on both security and development efficiency. DevSecOps emphasizes the shift-left approach, where security is integrated early in the software development lifecycle (SDLC) to identify and mitigate vulnerabilities before they reach production. By embedding security practices into CI/CD workflows, organizations can achieve continuous security validation and testing in tandem with software development activities. Key components of a successful DevSecOps implementation include automated security testing, real-time vulnerability scanning, infrastructure as code (IaC) security, and threat intelligence integration. Through the use of tools like static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA), DevSecOps facilitates the continuous monitoring of code, configurations, and infrastructure for security issues. This paper also examines the cultural shift required to adopt DevSecOps within development teams. It highlights the importance of fostering collaboration between development, security, and operations teams to ensure seamless integration of security practices into the CI/CD pipeline. By aligning security teams with development and operations, DevSecOps fosters a culture of shared responsibility for security, breaking down silos that traditionally hinder effective security integration.

Security affects every software component in different types of computing systems. Many vulnerabilities and attacks on software systems are due to security weaknesses in the software itself. During the process of software specification, development, or testing, security issues are either taken into consideration insufficiently or not at all. Such software, due to internal weaknesses is prone to new attacks. By teaching secure software engineering techniques for designing and developing software modules, students would learn systematic secure software development techniques, such as defect detecting and security testing. This paper presents a series of modules that are designed to be integrated into undergraduate software engineering courses from a security perspective. The goal of the modules is to teach the building of robust software security requirements, secure software design and development, and secure software verification through a secure software development lifecycle.

e-Tendering is an electronic processing of the tender document via internet and allow tenderer to publish, communicate, access, receive and submit all tender related information and documentation via internet.This study aims to design the e-Tendering system using Rational Unified Process approach.RUP provides a disciplined approach on how to assign tasks and responsibilities within the software development process. RUP has four phases that can assist researchers to adjust the requirements of various projects with different scope, problem and the size of projects. RUP is characterized as a use case driven, architecture centered, iterative and incremental process model. However the scope of this study only focusing on Inception and Elaboration phases as step to develop the model and perform only three of nine workflows (business modeling, requirements, analysis and design). RUP has a strong focus on documents and the activities in the inception and elaboration phases mainly concern the creation of diagrams and writing of textual descriptions. The UML notation and the software program, Star UML are used to support the design of e-Tendering. The e-Tendering design based on the RUP approach can contribute to e-Tendering developers and researchers in e-Tendering domain.In addition, this study also shows that the RUP is one of the best system development methodology that can be used as one of the research methodology in Software Engineering domain related to secured design of any observed application.This methodology has been tested in various studies in certain domains, such as in Simulation-based Decision Support, Security Requirement Engineering, Business Modeling and Secure System Requirement, and so forth.As a conclusion, these studies showed that the RUP one of a good research methodology that can be adapted in any Software Engineering (SE) research domain that required a few artifacts to be generated such as use case modeling, misuse case modeling, activity diagram, and initial class diagram from a list of requirements as identified earlier by the SE researchers

Secure software engineering is concerned with developing software systems that will continue delivering its intended functionality despite a multitude of harmful software technologies that can attack these systems from anywhere and at anytime. Misuse cases and mal-activity diagrams are two techniques to model functional security requirements address security concerns early in the development life cycle. This allows system designers to equip their systems with security mechanisms built within system design rather than relying on external defensive mechanisms. In a model-driven engineering process, misuse cases are expected to drive the construction of mal-activity diagrams. However, a systematic approach to transform misuse cases into mal-activity diagrams is missing. Therefore, this process remains dependent on human skill and judgment, which raises the risk of developing mal-activity diagrams that are inconsistent with the security requirements described in misuse cases, leading to the development of an insecure system. This paper presents an authoring structure for misuse cases and a transformation technique to systematically perform this desired model transformation. A study was conducted to evaluate the proposed technique using 46 attack stories outlined in a book by a former well-known hacker (Mitnick and Simon in The art of deception: controlling the human element of security, Wiley, Indianapolis, 2002). The results indicate that applying the proposed technique produces correct mal-activity diagrams from misuse cases.

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.

Agile methodologies are becoming increasingly common on Software Engineering Teams. Unfortunately, their relation with the security activities is complex to approach, even more complex when the Security Team has strong requirements of independence. This paper shows a case study of a software security testing process, based on the Microsoft Software Development Lifecycle for Agile, on a company moving their Software Engineering Teams from waterfall to agile. The results of this case study show a successful synchronization between the tasks of agile Software Engineering Teams and the independent Security Team.