Systematically Developing Prevention, Detection, and Response Patterns for Security Requirements

Riaz, Muhammad Mohsin; Elder, Sarah; Williams, Laurie

doi:10.1109/rew.2016.025

Cited by 9 publications

(7 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The coverage is significantly better in three out of the four studies as well as in the combined analysis. Putting more effort into identifying a comprehensive set of security requirements templates is also warranted (Riaz, Elder et al 2016) based on our findings.…”

Section: Discussionmentioning

confidence: 87%

Identifying the implied: Findings from three differentiated replications on the use of security requirements templates

et al. 2016

Self Cite

View full text Add to dashboard Cite

Context: Identifying security requirements early on can lay the foundation for secure software development. Security requirements are often implied by existing functional requirements but are mostly left unspecified. The Security Discoverer process automatically identifies security implications of individual requirements sentences and suggests applicable security requirements templates.Goal: To support requirements analysts in identifying security requirements by automating the suggestion of security requirements templates that are implied by existing functional requirements. Method:We conducted a controlled experiment in a graduate-level security class at North Carolina State University (NCSU) to evaluate the Security Discoverer (SD) process in eliciting implied security requirements in 2014. We have subsequently conducted three differentiated replications to evaluate the generalizability and applicability of the initial findings. The replications were conducted across three countries at the University of Trento, NCSU, and the University of Costa Rica. We evaluated the responses of the 205 total participants in terms of quality, coverage, relevance and efficiency. We also develop shared insights regarding the impact of context factors such as time, motivation and support, on the study outcomes and provide lessons learned in conducting the replications.Results: Treatment group, using the SD process, performed significantly better than the control group (at p-value <0.05) in terms of the coverage of the identified security requirements and efficiency of the requirements elicitation process in two of the three replications, supporting the findings of the original study. Participants in the treatment group identified 84% more security requirements in the oracle as compared to the control group on average. Overall, 80% of the 111 participants in the treatment group were favorable towards the use of templates in identifying security requirements. Our qualitative findings indicate that participants may be able to differentiate between relevant and extraneous templates suggestions and be more inclined to fill in the templates with additional support. Conclusion:Security requirements templates capture the security knowledge of multiple experts and can support the security requirements elicitation process when automatically suggested, making the implied security requirements more evident. However, individual participants may still miss out on identifying a number of security requirements due to empirical constraints as well as potential limitations on knowledge and security expertise.

show abstract

Section: Discussionmentioning

confidence: 87%

Identifying the implied: Findings from three differentiated replications on the use of security requirements templates

et al. 2016

Self Cite

View full text Add to dashboard Cite

show abstract

“…-Elicit the security concerns: It is important to identify the sub-characteristics of security associated with the identified security features and requirements (in Table 1). For instance, for the feature/requirement, "the customer must authenticate to the AMI to access the information", essential aspects relevant to security such as goal, tasks are presented in The details of security tasks to achieve the authentication goal have considered the same way as identified by Riaz et al, (2016).…”

Section: Instantiating the Ifusmentioning

confidence: 99%

“…The details of each activity during the five phases of IFUS are as follows: Access software requirement specification document : To initiate the process, security and usability experts access the software requirement specification (SRS) to enumerate security requirements. Different knowledge sources can be used to initiate pattern writing, including individual experiences, standards and best practices, specifications and documents (Riaz et al , 2016). IFUS uses the SRS document for the said purpose. Enumerate the security features and focus areas : The security and usability experts access the SRS document to identify the security requirements of the system.…”

Section: Integrative Framework For Usable Securitymentioning

confidence: 99%

“…Access software requirement specification document : To initiate the process, security and usability experts access the software requirement specification (SRS) to enumerate security requirements. Different knowledge sources can be used to initiate pattern writing, including individual experiences, standards and best practices, specifications and documents (Riaz et al , 2016). IFUS uses the SRS document for the said purpose.…”

Section: Integrative Framework For Usable Securitymentioning

confidence: 99%

See 1 more Smart Citation

Incorporating the human facet of security in developing systems and services

Naqvi

Clarke

Porras

2020

ICS

View full text Add to dashboard Cite

Purpose The purpose of this paper is to present an integrative framework for handling the security and usability conflicts during the system development lifecycle. The framework has been formulated while considering key concerns raised after conducting a series of interviews with practitioners from the industry. The framework is aimed at assisting system designers and developers in making reasonably accurate choices when it comes to the trade-offs between security and usability. The outcomes of using the framework are documented as design patterns, which are disseminated among the community of system designers and developers for use in other but similar contexts. Design/methodology/approach A design science research approach was used to develop the integrative framework for usable security. Interviews were conducted for identification of the key concerns; however, the framework was validated during a workshop. Moreover, to validate the patterns’ template and the usable security pattern identified after instantiating the framework, a survey instrument was used. Findings It is important to consider the usability aspect in the development of security systems; otherwise, the systems, despite being secure against attacks, would be susceptible to user mistakes leading to compromises. It is worthwhile to handle usable security concerns right from the start of system development life cycle. Design patterns can help the developers in assessing the usability of their security options. Practical implications Practical implications The framework would assist the designers and developers in handling the security and usability conflicts right from the start of the system development life cycle. The patterns documented after using the framework would help not only the designers and developers working in the industry but also freelancers. Originality/value The authors present a novel framework to handle the security and usability conflicts during the system development life cycle. The development process of the framework was driven by the concerns raised after a series of interviews with the practitioners from industry. The framework presented in this paper was validated during a workshop in which it was exposed for review and comments by the participants from the industry. To demonstrate the use of patterns in general and the framework in particular, a case study featuring smart grids from the domain of cyber-physical systems is presented, which (to the best of the authors’ knowledge) features the first work relevant to usable security in the domain of cyber-physical systems.

show abstract

“…They can also view the examples of each component if needed (11). Finally, he can view the overall completeness for all requirements (9) and Lew can decide whether to proceed with the requirements or amend it (10).…”

Section: Figure 2: User Interface Of Securemereq In Usedmentioning

confidence: 99%

Secure MEReq: A Tool Support to Check for Completeness of Security Requirements

2019

IJRTE

View full text Add to dashboard Cite

Quality security requirements help secure software development to succeed. While considerable research can be discovered in the field of demands elicitation, less attention has been paid to the writing of full security specifications. The demands engineers (REs) are still challenged and tedious in implementing and reporting full safety needs derived from Natural language. This is due to their tendency to misunderstand the real needs and the security terms used by inexperienced REs leading to incomplete security requirements. Motivated from these problems, we have developed a prototype tool, called SecureMEReq to improve the writing of complete security requirements. This tool provides four important key-features, which are (1) extraction of template-based components from client-stakeholders; (2) analysis of template-based density from SRCLib; (3) analysis of requirements syntax density from SecLib; and (4) analysis of completeness prioritization. To do this, we used our pattern libraries: SecLib and SRCLib to support the automation process of elicitation, especially in writing the security requirements. Our evaluation results show that our prototype tool is capable to facilitate the writing of complete security requirements and useful in assisting the REs to elicit the security requirements.

show abstract

Systematically Developing Prevention, Detection, and Response Patterns for Security Requirements

Cited by 9 publications

References 7 publications

Identifying the implied: Findings from three differentiated replications on the use of security requirements templates

Identifying the implied: Findings from three differentiated replications on the use of security requirements templates

Incorporating the human facet of security in developing systems and services

Secure MEReq: A Tool Support to Check for Completeness of Security Requirements

Contact Info

Product

Resources

About