Threat Modelling
This section is dedicated to threat modelling, for the development of secure practises.
Glossary
Threat Modelling
"A form of risk assessment that models aspects of the attack and defense sides of a logical entity, such as a piece of data, an application, a host, a system, or an environment." ( NIST )
Reflection
In the last module, I talked about my curiosity with 'model-based reasoning', which stemmed from the observation that models are tools for design, project management and scientific discourse. Naturally, I wanted to learn more about security models, so I decided to create a section on threat modelling. Eventually, I plan on cataloguing models from different domains for educational purposes .
Application Modelling
Readings
- Pauli, J. & Xu, D. (2005) 'Misuse case-based design and analysis of secure software architecture'. International Conference on Information Technology: Coding and Computing (ITCC'05) - Volume II. Las Vegas, USA, 2005. - Pauli and Xu propose the use of use case and misuse case diagrams to assist with the design and analysis of secure software.
- Peralta, K., Orozco, A., Zorzo, A., & Oliveira, F. (2008) 'Specifying Security Aspects in UML Models', Proceedings of the Workshop on Modelling Security (MODSEC08) held as part of the 2008 International Conference on Model Driven Engineering Languages and Systems (MODELS). Toulouse, France, 2008. - Peralta et al present a stereotype format to mark vulnerabilities on UML diagrams.
Response to Pauli & Xu (2005)
I agree with Pauli and Xu that misuse case diagrams provide can a smooth transition between requirements gathering and secure software design. Misuse case diagrams are similar to use case diagrams, which are easy to use, and the traceability that misuse case diagrams provide is valuable, especially in pipelined development, where correlations between requirements and deployment phases can be observed, and adjustments to the pipeline can be made accordingly. That being said, the simplicity of misuse case diagrams is also a weakness, and I'd argue that they are not sufficent for capturing the full complexity of security requirements due to the nature of time in exploitations. Vulnerabilities might show themselves when the software is in particular states for example. So I think activity diagrams are also required to smoothen the transition from requirements gathering to software design, and capture those details.
Peer Discussion
This was my initial submission to a discussion activity, in which we were asked to discuss which UML model are most suitable for designing security solutions to a chosen vulnerability:
"'Injection' attacks made it onto OWASP's most recent Top10 software vulnerabilities, which were decided by considering how exploitable the vulnerabilities are and how impactful those exploits could be[1]. Being somewhat familiar with SQL, I wanted to discuss SQL injections specifically.
Description of SQL Injections
OWASP links each vulnerability to Mitres' Common Weakness Enumeration entry of it, a database which gives the following description of an SQL attack:"[The use of] user-controllable inputs, [so] the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data"[2].
To understand the potential impact of SQL injections, it's standard to relate them to the CIA triad of ideal information assurances [3].
1. Confidentiality ~ SQL injections can facilitate the exposure of sensitive data.
2. Integrity ~ SQL injections can facilitate the alteration of data.
3. Availability - SQL injections can facilitate the destruction of data.
The following flow chart aims to show how malicious SQL injections are performed:
OWASP provides a theoretical example of an SQL injection[4], for the curious. Do you know of any ways to prevent SQL injections?
Model-based Security
Being accustomed to UML, it would be really convenient to be able to model security vulnerabilities using it. By modelling security vulnerabilities, we are more likely to remember to implement security protection in our software when implementing those models.
One way security proactivity is achievable, is by using UML extension entities such as stereotypes and tags. There are multiple variations of how these might be formatted, such as using the Object Constraint Language (OCL)[5], or not [6]. As OCL looks intimidating, I think it's less likely to be adopted by new developers, who are most likely to be unaware of security vulnerabilities, so I definitely favour the friendlier version.
The following activity diagram aims to be an example of a visually informative use of stereotypes and tags to
indicate a security vulnerability. The stereotype and tag construction
I've used is one that's been recommended [7]. Specifically, in the diagram, the stereotype is '<
Out of all possible UML diagrams, I think activity diagrams are the most generally useful diagrams for marking security vulnerabilities. Some of the reasons for that include:
- The granularity of detail can be finetuned to suit either developers or other stakeholders.
- Activity diagrams are behaviour diagrams, so vulnerabilities can be situated within the flow of the software. As a developer, I would find that extra helpful.
There's definitely arguments to be made for other diagrams such as class and package diagrams, which catalogue some of the components for developers to make use of, but at this point in time, I would somewhat validate those diagrams by referring to an activity diagram. Do you find activity diagrams useful?
Software Development Lifecycles
Lastly, I wanted to bring up the task of integrating model-based security into a software development lifecycle. In a secure scrum framework, would it be beneficial to link s-tags[8] to specific activities on an activity diagram associated with security vulnerabilities, for tracking security developments?
References
[1] OWASP. (2021) OWASP TOP10. Available from: https://owasp.org/Top10/ [Accessed 4 May 2023].
[2] MITRE. (2023) CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). Available from: https://cwe.mitre.org/data/definitions/89.html [Accessed 4 May 2023].
[3] CIS. (2023) Election Security Spotlight - CIA Triad. Available from: https://www.cisecurity.org/insights/spotlight/ei-isac-cybersecurity-spotlight-cia-triad [Accessed 4 May 2023].
[4] OWASP. (2023) Testing for SQL Injection. Available from: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection [Accessed 4 May 2023].
[5] Salas, P., Krishnan, P. & Ross, K. (2007) 'Model-Based Security Vulnerability Testing', 2007 Australian Software Engineering Conference (ASWEC'07). Melbourne, Australia, 2007. New York: IEEE. 284-296. Available from: https://doi.org/10.1109/ASWEC.2007.31 [Accessed 4 May 2023].
[6] Jürjen, J. (2002) 'UMLsec: Extending UML for Secure Systems Development', in: Jézéquel, J., Hussmann, H. & Cook, S. (eds) <
[7] Peralta, K., Orozco, A., Zorzo, A., & Oliveira, F. (2008) 'Specifying Security Aspects in UML Models', Proceedings of the Workshop on Modelling Security (MODSEC08) held as part of the 2008 International Conference on Model Driven Engineering Languages and Systems (MODELS). Toulouse, France, 2008. Germany: CEUR-WS. Available from: https://ceur-ws.org/Vol-413/ [Accessed 4 May 2023].
[8] Pohl, C. & Hof, H. (2015) 'Secure Scrum: Development of Secure Software with Scrum', The Ninth International Conference on Emerging Security Information, Systems and Technologies - SECURWARE 2015. Venice, Italy, 2015. Available from: https://doi.org/10.48550/arXiv.1507.02992 [Accessed 4 May 2023].
Bibliography
OMG. (2014) About the Object Constraint Language. Specification Version 2.4. Available from: https://www.omg.org/spec/OCLF [Accessed 4 May 2023].
OMG. (2017) About the Unified Modelling Language. Specification Version 2.5.1. Available from: https://www.omg.org/spec/UML/2.5.1/About-UML#document-metadata [Accessed 4 May 2023].
To read the responses to this post, and my response to the post of others, click here.
Group Project
This was my contribution to a group project, in which we were asked to design and implement secure software. I modelled planned defenses against threats using an activity diagram. I decided to stick to the UML specification 2.5.1, so I made use of swimlanes to encapsulate the security layer of our application as below:
To read my groups complete, secure software design proposal, click here.