@article{riaz_king_slankas_williams_massacci_quesada-lopez_jenkins_2017, title={Identifying the implied: Findings from three differentiated replications on the use of security requirements templates}, volume={22}, ISSN={["1573-7616"]}, url={https://doi.org/10.1007/s10664-016-9481-1}, DOI={10.1007/s10664-016-9481-1}, abstractNote={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 (SD) process automatically identifies security implications of individual requirements sentences and suggests applicable security requirements templates. The objective of this research is to support requirements analysts in identifying security requirements by automating the suggestion of security requirements templates that are implied by existing functional requirements. We conducted a controlled experiment in a graduate-level security class at North Carolina State University (NCSU) to evaluate the 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. 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. 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.}, number={4}, journal={EMPIRICAL SOFTWARE ENGINEERING}, author={Riaz, Maria and King, Jason and Slankas, John and Williams, Laurie and Massacci, Fabio and Quesada-Lopez, Christian and Jenkins, Marcelo}, year={2017}, month={Aug}, pages={2127–2178} }
 @article{king_stallings_riaz_williams_2017, title={To log, or not to log: using heuristics to identify mandatory log events - a controlled experiment}, volume={22}, ISSN={["1573-7616"]}, url={https://doi.org/10.1007/s10664-016-9449-1}, DOI={10.1007/s10664-016-9449-1}, number={5}, journal={EMPIRICAL SOFTWARE ENGINEERING}, author={King, Jason and Stallings, Jon and Riaz, Maria and Williams, Laurie}, year={2017}, month={Oct}, pages={2684–2717} }
 @inproceedings{systematically developing prevention, detection, and response patterns for security requirements_2016, booktitle={2016 IEEE 24th International Requirements Engineering Conference Workshops (REW)}, year={2016}, pages={62–67} }
 @article{riaz_breaux_williams_2015, title={How have we evaluated software pattern application? A systematic mapping study of research design practices}, volume={65}, ISSN={["1873-6025"]}, DOI={10.1016/j.infsof.2015.04.002}, abstractNote={Software patterns encapsulate expert knowledge for constructing successful solutions to recurring problems. Although a large collection of software patterns is available in literature, empirical evidence on how well various patterns help in problem solving is limited and inconclusive. The context of these empirical findings is also not well understood, limiting applicability and generalizability of the findings. To characterize the research design of empirical studies exploring software pattern application involving human participants. We conducted a systematic mapping study to identify and analyze 30 primary empirical studies on software pattern application, including 24 original studies and 6 replications. We characterize the research design in terms of the questions researchers have explored and the context of empirical research efforts. We also classify the studies in terms of measures used for evaluation, and threats to validity considered during study design and execution. Use of software patterns in maintenance is the most commonly investigated theme, explored in 16 studies. Object-oriented design patterns are evaluated in 14 studies while 4 studies evaluate architectural patterns. We identified 10 different constructs with 31 associated measures used to evaluate software patterns. Measures for ‘efficiency’ and ‘usability’ are commonly used to evaluate the problem solving process. While measures for ‘completeness’, ‘correctness’ and ‘quality’ are commonly used to evaluate the final artifact. Overall, ‘time to complete a task’ is the most frequently used measure, employed in 15 studies to measure ‘efficiency’. For qualitative measures, studies do not report approaches for minimizing biases 27% of the time. Nine studies do not discuss any threats to validity. Subtle differences in study design and execution can limit comparison of findings. Establishing baselines for participants’ experience level, providing appropriate training, standardizing problem sets, and employing commonly used measures to evaluate performance can support replication and comparison of results across studies.}, journal={INFORMATION AND SOFTWARE TECHNOLOGY}, author={Riaz, Maria and Breaux, Travis and Williams, Laurie}, year={2015}, month={Sep}, pages={14–38} }
 @inproceedings{riaz_king_slankas_williams_2014, title={Hidden in plain sight: Automatically identifying security requirements from natural language artifacts}, DOI={10.1109/re.2014.6912260}, abstractNote={Natural language artifacts, such as requirements specifications, often explicitly state the security requirements for software systems. However, these artifacts may also imply additional security requirements that developers may overlook but should consider to strengthen the overall security of the system. The goal of this research is to aid requirements engineers in producing a more comprehensive and classified set of security requirements by (1) automatically identifying security-relevant sentences in natural language requirements artifacts, and (2) providing context-specific security requirements templates to help translate the security-relevant sentences into functional security requirements. Using machine learning techniques, we have developed a tool-assisted process that takes as input a set of natural language artifacts. Our process automatically identifies security-relevant sentences in the artifacts and classifies them according to the security objectives, either explicitly stated or implied by the sentences. We classified 10,963 sentences in six different documents from healthcare domain and extracted corresponding security objectives. Our manual analysis showed that 46% of the sentences were security-relevant. Of these, 28% explicitly mention security while 72% of the sentences are functional requirements with security implications. Using our tool, we correctly predict and classify 82% of the security objectives for all the sentences (precision). We identify 79% of all security objectives implied by the sentences within the documents (recall). Based on our analysis, we develop context-specific templates that can be instantiated into a set of functional security requirements by filling in key information from security-relevant sentences.}, booktitle={2014 ieee 22nd international requirements engineering conference (re)}, author={Riaz, M. and King, Jason and Slankas, J. and Williams, L.}, year={2014}, pages={183–192} }
 @inproceedings{hibshi_breaux_riaz_williams_2014, title={Towards a framework to measure security expertise in requirements analysis}, DOI={10.1109/espre.2014.6890522}, abstractNote={Research shows that commonly accepted security requirements are not generally applied in practice. Instead of relying on requirements checklists, security experts rely on their expertise and background knowledge to identify security vulnerabilities. To understand the gap between available checklists and practice, we conducted a series of interviews to encode the decision-making process of security experts and novices during security requirements analysis. Participants were asked to analyze two types of artifacts: source code, and network diagrams for vulnerabilities and to apply a requirements checklist to mitigate some of those vulnerabilities. We framed our study using Situation Awareness-a cognitive theory from psychology-to elicit responses that we later analyzed using coding theory and grounded analysis. We report our preliminary results of analyzing two interviews that reveal possible decision-making patterns that could characterize how analysts perceive, comprehend and project future threats which leads them to decide upon requirements and their specifications, in addition, to how experts use assumptions to overcome ambiguity in specifications. Our goal is to build a model that researchers can use to evaluate their security requirements methods against how experts transition through different situation awareness levels in their decision-making process.}, booktitle={2014 IEEE 1st Workshop on Evolving Security and Privacy Requirements Engineering (ESPRE)}, author={Hibshi, H. and Breaux, T. and Riaz, M. and Williams, L.}, year={2014}, pages={13–18} }