Formally Modeled Common Weakness Enumerations (CWEs)
Pages 88 - 93
Abstract
The Common Weakness Enumeration is a community-developed list of common software weaknesses, also known as CWEs, that could lead to exploitable security vulnerabilities. CWEs provide textual information related to weaknesses in the form of a structured, natural language text description. However, the lack of formal representation hinders the ability to perform rigorous, accurate, automated reasoning about potential security flaws and risks during the software development lifecycle. In this paper, we present a formal CWE-based software security model in the Alloy specification language. Our model allows software engineers to analyze software systems in terms of CWEs, thus supporting them in a wide range of reasoning tasks on security requirements, the detection of design issues, detecting inconsistencies between requirements and code, and more. We present our CWE model design, provide examples of several use cases for the early stages of the software engineering process, and discuss challenges and future work in this direction.
References
[1]
Bachmann, F., Bass, L., and Klein, M. Deriving architectural tactics: A step toward methodical architectural design. Citeseer, 2003.
[2]
Berger, B. J., Sohr, K., and Koschke, R. Automatically extracting threats from extended data flow diagrams. In Engineering Secure Software and Systems: 8th International Symposium, ESSoS 2016, London, UK, April 6--8, 2016. Proceedings 8 (2016), Springer, pp. 56--71.
[3]
Bojanova, I. Formalizing cybersecurity weaknesses and vulnerabilites.
[4]
Bojanova, I., and Guerrerio, J. J. Labeling software security vulnerabilities. IT Professional 25, 5 (2023), 64--70.
[5]
Bruckschen, M., Northfleet, C., Silva, D., Bridi, P., Granada, R., Vieira, R., Rao, P., and Sander, T. Named entity recognition in the legal domain for ontology population. In Workshop Programme (2010), Citeseer, p. 16.
[6]
Buneman, P., Khanna, S., and Wang-Chiew, T. Why and where: A characterization of data provenance. In Database Theory---ICDT 2001: 8th International Conference London, UK, January 4--6, 2001 Proceedings 8 (2001), Springer, pp. 316--330.
[7]
Calloni, N., and Campana, D. Embedded information systems technology support (eists). task order 0006: Vulnerability path analysis and demonstration (vpad). volume 2-white box definitions of software fault patterns. LOCKHEED MARTIN INC FORT WORTH TX, Tech. Rep. ADB381215 (2011).
[8]
Cao, K., Li, X., and Xing, J. Security software formal modeling and verification method based on uml and z. In Contemporary Research on E-business Technology and Strategy: International Conference, iCETS 2012, Tianjin, China, August 29--31, 2012, Revised Selected Papers (2012), Springer, pp. 390--401.
[9]
Chen, C., Grisham, P., Khurshid, S., and Perry, D. Design and validation of a general security model with the alloy analyzer. In Proceedings of the ACM SIGSOFT First Alloy Workshop (2006), Citeseer, pp. 38--47.
[10]
Cheney, J., Chiticariu, L., Tan, W.-C., et al. Provenance in databases: Why, how, and where. Foundations and Trends® in Databases 1, 4 (2009), 379--474.
[11]
Fazelnia, M., Okutan, A., and Mirakhorli, M. Supporting artificial intelligence/machine learning security workers through an adversarial techniques, tools, and common knowledge framework. IEEE Security & Privacy 21, 1 (2022), 37--48.
[12]
Fernández, D. M., Wagner, S., Kalinowski, M., Felderer, M., Mafra, P., Vetrò, A., Conte, T., Christiansson, M. T., Greer, D., Lassenius, C., Männistö, T., Nayabi, M., Oivo, M., Penzenstadler, B., Pfahl, D., Prikladnicki, R., Ruhe, G., Schekelmann, A., Sen, S., Spinola, R., Tuzcu, A., de la Vara, J. L., and Wieringa, R. Naming the pain in requirements engineering. Empirical Software Engineering 22, 5 (2017), 2298--2338.
[13]
Gandhi, R., Siy, H., and Wu, Y. Lightweight formal models of software weaknesses. In 2013 1st FME Workshop on Formal Methods in Software Engineering (FormaliSE) (2013), IEEE, pp. 50--56.
[14]
Gandhi, R. A., and Rahmani, M. Early security patterns: A collection of constraints to describe regulatory security requirements. In 2012 Second IEEE International Workshop on Requirements Patterns (RePa) (2012), IEEE, pp. 17--22.
[15]
Georg, G., Ray, I., Anastasakis, K., Bordbar, B., Toahchoodee, M., and Houmb, S. H. An aspect-oriented methodology for designing secure applications. Information and Software Technology 51, 5 (2009), 846--864.
[16]
Green, T. J., Karvounarakis, G., and Tannen, V. Provenance semirings. In Proceedings of the twenty-sixth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems (2007), pp. 31--40.
[17]
Herschel, M., Diestelkämper, R., and Ben Lahmar, H. A survey on provenance: What for? what form? what from? The VLDB Journal 26 (2017), 881--906.
[18]
Heyman, T., Scandariato, R., and Joosen, W. Security in context: Analysis and refinement of software architectures. In 2010 IEEE 34th Annual Computer Software and Applications Conference (2010), IEEE, pp. 161--170.
[19]
Hilbrich, M., and Frank, M. Enforcing security and privacy via a cooperation of security experts and software engineers: a model-based vision. In 2017 IEEE 7th International Symposium on Cloud and Service Computing (SC2) (2017), IEEE, pp. 237--240.
[20]
Jackson, D. Alloy: a lightweight object modelling notation. ACM Transactions on Software Engineering and Methodology (TOSEM) 11, 2 (2002), 256--290.
[21]
Jackson, D. Software Abstractions: logic, language, and analysis. MIT press, 2012.
[22]
Jackson, D. Alloy: a language and tool for exploring software designs. Communications of the ACM 62, 9 (2019), 66--76.
[23]
Knauss, E., Houmb, S., Schneider, K., Islam, S., and Jürjens, J. Supporting requirements engineers in recognising security issues. In International Working Conference on Requirements Engineering: Foundation for Software Quality (2011), Springer, pp. 4--18.
[24]
Li, H., Li, X., Hao, J., Xu, G., Feng, Z., and Xie, X. Fesr: A framework for eliciting security requirements based on integration of common criteria and weakness detection formal model. In 2017 IEEE International Conference on Software Quality, Reliability and Security (QRS) (2017), IEEE, pp. 352--363.
[25]
Liu, L., Yu, E., and Mylopoulos, J. Security and privacy requirements analysis within a social setting. In Proceedings. 11th IEEE International Requirements Engineering Conference, 2003. (2003), IEEE, pp. 151--161.
[26]
Macedo, N., and Cunha, A. Automatic unbounded verification of alloy specifications with prover9. arXiv preprint arXiv:1209.5773 (2012).
[27]
Mahmood, B. Prioritizing cwe/sans and owasp vulnerabilities: A network-based model. International Journal of Computing and Digital Systems 10, 1 (2021), 361--372.
[28]
Márquez, G., Astudillo, H., and Kazman, R. Architectural tactics in software architecture: A systematic mapping study. Journal of Systems and Software 197 (2023), 111558.
[29]
MITRE. Common weakness enumeration. https://cwe.mitre.org/index.html, 2022. (Accessed on 03/31/2024).
[30]
Nelson, T., Danas, N., Dougherty, D. J., and Krishnamurthi, S. The power of "why" and "why not": Enriching scenario exploration with provenance. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (2017), pp. 106--116.
[31]
Rouland, Q., Hamid, B., and Jaskolka, J. Specification, detection, and treatment of stride threats for software components: Modeling, formal methods, and tool support. Journal of Systems Architecture 117 (2021), 102073.
[32]
Santos, J. C., Tarrit, K., and Mirakhorli, M. A catalog of security architecture weaknesses. In 2017 IEEE International Conference on Software Architecture Workshops (ICSAW) (2017), IEEE, pp. 220--223.
[33]
Schaad, A., and Binder, D. Ml-supported identification and prioritization of threats in the ovvl threat modelling tool. In Data and Applications Security and Privacy XXXIV: 34th Annual IFIP WG 11.3 Conference, DBSec 2020, Regensburg, Germany, June 25--26, 2020, Proceedings 34 (2020), Springer, pp. 274--285.
[34]
Tuma, K., Hosseini, D., Malamas, K., and Scandariato, R. Inspection guidelines to identify security design flaws. In Proceedings of the 13th European Conference on Software Architecture-Volume 2 (2019), pp. 116--122.
[35]
Tuma, K., Sion, L., Scandariato, R., and Yskout, K. Automating the early detection of security design flaws. In Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (2020), pp. 332--342.
[36]
Varela-Vaca, A. J., and Gasca, R. M. Formalization of security patterns as a means to infer security controls in business processes. Logic Journal of the IGPL 23, 1 (2015), 57--72.
[37]
Woodcock, J., Larsen, P. G., Bicarregui, J., and Fitzgerald, J. Formal methods: Practice and experience. ACM computing surveys (CSUR) 41, 4 (2009), 1--36.
[38]
Wu, Y., Bojanova, I., and Yesha, Y. They know your weaknesses-do you?: Reintroducing common weakness enumeration. CrossTalk 45 (2015).
[39]
Wu, Y., Gandhi, R. A., and Siy, H. Using semantic templates to study vulnerabilities recorded in large software repositories. In Proceedings of the 2010 ICSE Workshop on Software Engineering for Secure Systems (2010), pp. 22--28.
Index Terms
- Formally Modeled Common Weakness Enumerations (CWEs)
Recommendations
Composable semantics for model-based notations
SIGSOFT '02/FSE-10: Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineeringWe propose a unifying framework for model-based specification notations. Our framework captures the execution semantics that are common among model-based notations, and leaves the distinct elements to be defined by a set of parameters. The basic ...
Composable semantics for model-based notations
We propose a unifying framework for model-based specification notations. Our framework captures the execution semantics that are common among model-based notations, and leaves the distinct elements to be defined by a set of parameters. The basic ...
Real-time rewriting semantics of orc
PPDP '07: Proceedings of the 9th ACM SIGPLAN international conference on Principles and practice of declarative programmingOrc is a language proposed by Jayadev Misra [19] for orchestration of distributed services. Orc is very simple and elegant, based on a few basic constructs, and allows succinct and understandable programming of sophisticated applications. However, ...
Comments
Please enable JavaScript to view thecomments powered by Disqus.Information & Contributors
Information
Published In
October 2024
245 pages
ISBN:9798400712494
DOI:10.1145/3691621
- General Chair:
- Vladimir Filkov,
- Program Co-chairs:
- Baishakhi Ray,
- Minghui Zhou
This work is licensed under a Creative Commons Attribution International 4.0 License.
Sponsors
Publisher
Association for Computing Machinery
New York, NY, United States
Publication History
Published: 27 October 2024
Check for updates
Author Tags
Qualifiers
- Short-paper
Funding Sources
Conference
ASEW '24: 39th IEEE/ACM International Conference on Automated Software Engineering Workshops
October 27 - November 1, 2024
CA, Sacramento, USA
Contributors
Other Metrics
Bibliometrics & Citations
Bibliometrics
Article Metrics
- 0Total Citations
- 109Total Downloads
- Downloads (Last 12 months)109
- Downloads (Last 6 weeks)64
Reflects downloads up to 01 Jan 2025
Other Metrics
Citations
View Options
Login options
Check if you have access through your login credentials or your institution to get full access on this article.
Sign in