@article{elder_rahman_fringer_kapoor_williams_2024, title={A Survey on Software Vulnerability Exploitability Assessment}, volume={56}, ISSN={["1557-7341"]}, DOI={10.1145/3648610}, abstractNote={Knowing the exploitability and severity of software vulnerabilities helps practitioners prioritize vulnerability mitigation efforts. Researchers have proposed and evaluated many different exploitability assessment methods. The goal of this research is to assist practitioners and researchers in understanding existing methods for assessing vulnerability exploitability through a survey of exploitability assessment literature. We identify three exploitability assessment approaches: assessments based on original, manual CVSS, automated Deterministic assessments, and automated Probabilistic assessments. Other than the original CVSS, the two most common subcategories are Deterministic, Program-State-Based, and Probabilistic Learning Model (LM) Assessments.}, number={8}, journal={ACM COMPUTING SURVEYS}, author={Elder, Sarah and Rahman, Md Rayhanur and Fringer, Gage and Kapoor, Kunal and Williams, Laurie}, year={2024}, month={Aug} } @article{rahman_hezaveh_williams_2023, title={What Are the Attackers Doing Now? Automating Cyberthreat Intelligence Extraction from Text on Pace with the Changing Threat Landscape: A Survey}, volume={55}, ISSN={["1557-7341"]}, DOI={10.1145/3571726}, abstractNote={ Cybersecurity researchers have contributed to the automated extraction of CTI from textual sources, such as threat reports and online articles describing cyberattack strategies, procedures, and tools. The goal of this article is to aid cybersecurity researchers in understanding the current techniques used for cyberthreat intelligence extraction from text through a survey of relevant studies in the literature. Our work finds 11 types of extraction purposes and 7 types of textual sources for CTI extraction. We observe the technical challenges associated with obtaining available clean and labeled data for replication, validation, and further extension of the studies. We advocate for building upon the current CTI extraction work to help cybersecurity practitioners with proactive decision-making such as in threat prioritization and mitigation strategy formulation to utilize knowledge from past cybersecurity incidents. }, number={12}, journal={ACM COMPUTING SURVEYS}, author={Rahman, Md Rayhanur and Hezaveh, Rezvan Mahdavi and Williams, Laurie}, year={2023}, month={Dec} } @article{rahman_imtiaz_storey_williams_2022, title={Why secret detection tools are not enough: It's not just about false positives-An industrial case study}, volume={27}, ISSN={["1573-7616"]}, DOI={10.1007/s10664-021-10109-y}, abstractNote={Checked-in secrets in version-controlled software projects pose security risks to software and services. Secret detection tools can identify the presence of secrets in the code, commit changesets, and project version control history. As these tools can generate false positives, developers are provided with mechanisms to bypass the warnings generated from these tools. Providing this override mechanism can result in developers sometimes exposing secrets in software repositories. The goal of this article is to aid software security practitioners in understanding why‘ secrets are checked into repositories, despite being warned by tools, through an industrial case study of analysis of usage data of a secret detection tool and a survey of developers who bypassed the tool alert. In this case study, we analyzed the usage data of a checked-in secret detection tool used widely by a software company and we surveyed developers who bypassed the warnings generated by the tool. From the case study, we found that, despite developers classified 50% of the warning as false positive, developers also bypassed the warning due to time constraints, working with non-shipping projects, technical challenges of eliminating secrets completely from the version control history, technical debts, and perceptions that check-ins are low risk. We advocate practitioners and researchers to investigate the findings of our study further to improve secret detection tools and related development practices. We also advocate that organizations should insert secondary checks, as is done by the company we studied, to capture occasions where developers incorrectly bypass secret detection tools.}, number={3}, journal={EMPIRICAL SOFTWARE ENGINEERING}, author={Rahman, Md Rayhanur and Imtiaz, Nasif and Storey, Margaret-Anne and Williams, Laurie}, year={2022}, month={May} } @article{rahman_rahman_parnin_williams_2021, title={Security Smells in Ansible and Chef Scripts: A Replication Study}, volume={30}, ISBN={1557-7392}, DOI={10.1145/3408897}, abstractNote={ Context: Security smells are recurring coding patterns that are indicative of security weakness and require further inspection. As infrastructure as code (IaC) scripts, such as Ansible and Chef scripts, are used to provision cloud-based servers and systems at scale, security smells in IaC scripts could be used to enable malicious users to exploit vulnerabilities in the provisioned systems. Goal: The goal of this article is to help practitioners avoid insecure coding practices while developing infrastructure as code scripts through an empirical study of security smells in Ansible and Chef scripts. Methodology: We conduct a replication study where we apply qualitative analysis with 1,956 IaC scripts to identify security smells for IaC scripts written in two languages: Ansible and Chef. We construct a static analysis tool called Security Linter for Ansible and Chef scripts (SLAC) to automatically identify security smells in 50,323 scripts collected from 813 open source software repositories. We also submit bug reports for 1,000 randomly selected smell occurrences. Results: We identify two security smells not reported in prior work: missing default in case statement and no integrity check. By applying SLAC we identify 46,600 occurrences of security smells that include 7,849 hard-coded passwords. We observe agreement for 65 of the responded 94 bug reports, which suggests the relevance of security smells for Ansible and Chef scripts amongst practitioners. Conclusion: We observe security smells to be prevalent in Ansible and Chef scripts, similarly to that of the Puppet scripts. We recommend practitioners to rigorously inspect the presence of the identified security smells in Ansible and Chef scripts using (i) code review, and (ii) static analysis tools. }, number={1}, journal={ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY}, author={Rahman, Akond and Rahman, Md Rayhanur and Parnin, Chris and Williams, Laurie}, year={2021}, month={Jan} } @article{rahman_mahdavi-hezaveh_williams_2020, title={A Literature Review on Mining Cyberthreat Intelligence from Unstructured Texts}, ISSN={["2375-9232"]}, DOI={10.1109/ICDMW51313.2020.00075}, abstractNote={Cyberthreat defense mechanisms have become more proactive these days, and thus leading to the increasing incorporation of cyberthreat intelligence (CTI). Cybersecurity researchers and vendors are powering the CTI with large volumes of unstructured textual data containing information on threat events, threat techniques, and tactics. Hence, extracting cyberthreat-relevant information through text mining is an effective way to obtain actionable CTI to thwart cyberattacks. The goal of this research is to aid cybersecurity researchers understand the source, purpose, and approaches for mining cyberthreat intelligence from unstructured text through a literature review of peer-reviewed studies on this topic. We perform a literature review to identify and analyze existing research on mining CTI. By using search queries in the bibliographic databases, 28,484 articles are found. From those, 38 studies are identified through the filtering criteria which include removing duplicates, non-English, non-peer-reviewed articles, and articles not about mining CTI. We find that the most prominent sources of unstructured threat data are the threat reports, Twitter feeds, and posts from hackers and security experts. We also observe that security researchers mined CTI from unstructured sources to extract Indicator of Compromise (IoC), threat-related topic, and event detection. Finally, natural language processing (NLP) based approaches: topic classification; keyword identification; and semantic relationship extraction among the keywords are mostly availed in the selected studies to mine CTI information from unstructured threat sources.}, journal={20TH IEEE INTERNATIONAL CONFERENCE ON DATA MINING WORKSHOPS (ICDMW 2020)}, author={Rahman, Md Rayhanur and Mahdavi-Hezaveh, Rezvan and Williams, Laurie}, year={2020}, pages={516–525} } @article{rahman_rahman_williams_2019, title={Share, But Be Aware: Security Smells in Python Gists}, ISSN={["1063-6773"]}, DOI={10.1109/ICSME.2019.00087}, abstractNote={Github Gist is a service provided by Github which is used by developers to share code snippets. While sharing, developers may inadvertently introduce security smells in code snippets as well, such as hard-coded passwords. Security smells are recurrent coding patterns that are indicative of security weaknesses, which could potentially lead to security breaches. The goal of this paper is to help software practitioners avoid insecure coding practices through an empirical study of security smells in publicly-available GitHub Gists. Through static analysis, we found 13 types of security smells with 4,403 occurrences in 5,822 publicly-available Python Gists. 1,817 of those Gists, which is around 31%, have at least one security smell including 689 instances of hard-coded secrets. We also found no significance relation between the presence of these security smells and the reputation of the Gist author. Based on our findings, we advocate for increased awareness and rigorous code review efforts related to software security for Github Gists so that propagation of insecure coding practices are mitigated.}, journal={2019 IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE AND EVOLUTION (ICSME 2019)}, author={Rahman, Md Rayhanur and Rahman, Akond and Williams, Laurie}, year={2019}, pages={536–540} }