Programming Secure Software Systems
Case Study: Safe programming issues
Related outcomes from the unit outline:
1. Analyse the existence of vulnerabilities inherent in insecure software products
2. Assure quality by using elements of a secure framework
3. Judge the effectiveness of mitigation strategies for security vulnerabilities
Marks allocation: Worth 35% of the total mark for this unit
Submission instructions:
To be submitted electronically via Blackboard.
Plagiarism:
Please ensure that you have read and understood the information on academic misconduct provided on BlackBoard.
Case Description: Tool-supported Modelling of Security Requirements Use cases as part of requirements engineering are often seen as an essential part of systems development in many methodologies. Given that modern, security-oriented software development methods such as SDL, SQUARE and CLASP place security at the forefront of product initiation, design and implementation, the focus of requirements elicitation must now move to capturing security requirements so as not to replicate past errors.
Obviously, if safe programming practices were followed, systems would not have the range of vulnerabilities that they do. Are there ways to capture the potential vulnerabilities before implementation by considering potential problems and eliciting security requirements in the early stages of system development? Misuse cases can be an effective tool to model security requirements, however their application is non-trivial and requires substantial knowledge to be effective. Therefore, tool support is essential.

Create a : Misuse Cases
Related learning outcomes from the unit outline:
• Assure quality by using elements of a secure framework.
• Judge the effectiveness of mitigation strategies for security vulnerabilities.
Background:
Use cases as part of requirements engineering are often seen as an essential part of systems development in many methodologies. Given that modern, security-oriented software development methods such as SDL, SQUARE and CLASP place security at the forefront of product initiation, design and implementation, the focus of requirements elicitation must now move to capturing security requirements so as not to replicate past errors. Misuse cases can be an effective tool to model security requirements.
Required Resources:
None
Optional Resources:
A UML editor such as Visio or Argo UML
Task: Find out about Misuse Case Diagrams
Read “Modelling misuse cases as a means of capturing security requirements”. Available at:
http://ro.ecu.edu.au/ism/120/
Task: Creating the Use Case Diagram
Read the Pet Shop case and draw a use case diagram of the functionality that you have discovered. See figure 1 for a base diagram that you can expand.
CSP3343/CSP4245 Page 1 of 3
MUC Construct S T R I D E
Actor X*
Mis-Actor (external) X X X X
Mis-Actor (internal) X X X X
Figure 1: Partial UCD derived from the Pet Shop Case Study.
Task: Create a Misuse Case Diagram
Save a separate copy of the UCD and add potential mis-actors (external and internal). For each mis-actor, use table 1 to identify misuse cases. Add these misuse cases (see “tamper with payment details” in figure 2) to your diagram. Use the «threatens» and «mitigates» stereotypes as appropriate to add security use cases (see “encrypt transaction” in figure 2).
In the same way that a use case can «include» another, a misuse case may also «include» the functionality of another misuse case. It may not, however, be obvious that the relationships between use cases and misuse cases are a) a use case can «mitigate» a misuse case; and b) a misuse case can «threaten» a use case.
Table 1: Mapping STRIDE to Misuse Case Elements.
* Actors may accidentally disclose information.
School of Science page 2
Figure 2: Partial Misuse Case Diagram derived from Figure 1.
Above you created a Diagram by generating candidate misuse cases using a STRIDE matrix. Given that the number of misuse cases could be potentially very large, is there a way to automatically generate a complete set of candidate misuse cases from information contained in a Use Case Diagram and/or a STRIDE matrix and then prune them, leaving a smaller set of viable misuse cases?
You should ask questions on the unit discussion board about the assignment in order to clarify ambiguities.
Key Deliverables
You need to submit several deliverables for this assignment in the areas of feasibility (F) requirements (R), design (D), implementation (I) and testing (T).
F – Research on the techniques you could use to solve the problem;
R – A list of the Requirements;
D – A design artifact (e.g., a class diagram);
I – The system itself (which need not be fully functional);
I – A ‘readme’ file which will explain how to install, configure and run the system. Note: This document shall be designed to assist your lecturer in assessing your deliverables – it is not intended to be a user manual; and
T – A test plan showing how you intend to show that your system conforms to the requirements (test case template in Appendix 1).
Teams
Given the scope of the assessment, you may choose to complete this assignment in small teams (max three people), but you are not required to do so.
The System Prototype
You may choose any development system/language to build your prototype (e.g. C, Python, Java, Swift etc.) as long as it can be demonstrated, delivered and marked as an assessable item. If, however, you choose a development environment that is not readily available (i.e. in the labs), then you are responsible for providing a legal copy of the environment otherwise your submission will not be assessed. Given that the prototype need not be fully functional to gain a passing grade, the use of stubs to indicate call/return values is recommended. You are welcome to use code from other sources provided that the code is available for non-commercial use and you acknowledge the source.
Referencing
All sources of references must be cited (in text citation) and listed (end reference list). For details about referencing and the required format, please refer to the ECU Referencing Guide.
You must:
• Provide a zip file containing your assignment as a Word document. The assignment should contain the deliverables mentioned above, apart from the Implementation deliverables. No other compression formats accepted. No other document formats accepted.
• In the zip file also include separately any other deliverables e.g., code, journal articles.
• You must include digital copies (in the zip file) of all references you cite in your assignment otherwise your assignment will not be accepted or assessed.
• Separately (not in the zip file), provide the MD5 hash value of your assignment (Word) document. Submissions without a hash value will not be accepted or assessed.
Document Style
• Your document must be in MS-Word format (.doc/.docx), body text 12 point Arial font, double spaced, fully justified and include page numbers.
• The document should include a title page and table of contents with page number one (1) starting after the table of contents.
• No executive summary or abstract required.
• The title page should not be numbered but the pages between the title page and the main body of the document should be numbered with lower case roman numerals.
Marks will be deducted if you do not adhere to this style.
Length: Unspecified.
Marks allocation:
10% Research (understanding of problem and solution)
10% System (prototype, conformance to requirements and design)
10% Test Plan (proof of execution, connection with requirements)
5% Spelling/grammar/quality
Hints and Tips:
Your prototype is not required to read a use case diagram so you need to define a model that can represent the elements of a use case diagram. I suggest XML as it can be parsed easily. For example:
?xml version=-1.0- encoding=-UTF-8-?
diagram title=-my use case diagram-
node id=-some actor-
relationship=-associate- target=-modify record-/
/node
node id=-modify record-
relationship=-include- target=-log in-/
relationship=-extend- target=-cancel-/
/node
/diagram
Notice that the constructs are generic. Having imported a structure similar to the above, applying a STRIDE matrix to the contents to generate misuse cases is straightforward.
Deciding which misuse cases are valid is, however, more challenging.
Appendix 1 Test Case Specification Sheet
Application System: KC Database 1.94 -- Single-User Version
Microsoft Access 2010 Version 9.0.4402 SR-1
Date: 12/03/2015 Test conducted by: JNM

Test id Test description Expected
behaviour/Evaluation criteria Outcome
T-01
Check that elements in the site (campus) table match the attributes within the data dictionary. All items in the data dictionary exist in the site (campus) table. Stated properties of items match. All specified attributes exist.
The name attribute of the site table has size 32 rather than 20.
Test Passed?: N
Action: Changed database schema to match specification.