Modelling Security Requirements

Modelling Security Requirements

Task:
Modelling Security Requirements
The Unified Modelling Language or UML is considered to be the de-facto standard for modelling information systems today. Despite this, there have been several extensions to the UML. One such extension involves what are called Misuse Case Diagrams, a security-oriented extension to the standard Use Case Diagrams. Security is a major concern for many mission-critical applications. If software were designed correctly the first time, vulnerabilities would not exist. Misuse Case Diagrams are an attempt to solve this problem Your task is to read the case study below, draw a use case diagram of the case study, and then draw a Misuse Case Diagram of the same problem. Before attempting the task, you should read Sindre and Opdahl (2001) to find out about misuse cases, then read Johnstone (2011) to find out how to generate a misuse case diagram with a STRIDE matrix. You should ask questions on the unit discussion board about the assignment in order to clarify ambiguities.
In your Word document include:
•    A Use Case Diagram of the Case Study described below;
• A Misuse Case Diagram derived from the above, using the method specified in Johnstone (2011);
• A STRIDE matrix
• A list of misuse cases derived from the above; and
• A list of security use cases derived from the above.
PCN
Case Study
Palladium Chain Nursing (PCN) wish to build a tablet-based app that allows health care professionals (HCPs) to sign up patients on-site. They have commissioned you, as an experienced security requirements engineer, to provide some initial models for their app. On start-up, the tablet performs a self-check to ascertain whether its operating system or the app have been tampered with. If the computed check sum does not match the checksum stored on a smart device that is connected to the tablet prior to start-up, then the tablet powers down again. The app must let an HCP authenticate to the PCN Health Server, where the patient records are also stored. Following authentication, an HCP can be authorised to create, modify or delete a patient record (with an appropriate audit trail). To create a record, the HCP asks the patient salient details and inputs the details into a form generated by the app. Following the creation of a patient record, an HCP can use the app to create a service contract between PCN and the patient. As part of the service contract, the patient’s health insurance fund may be optionally contacted by the app to confirm that the patient has the correct level of health insurance cover to allow him/her to be able to cover the cost of the service contract. To finalise the contract, the patient signs the form on the tablet in the appropriate place on the form. At that point the service contract is considered active once the data captured on the app is sent to the PCN Health Server.
Assignment 2:
Automatically Modelling Security Requirements In Assignment#1, you drew a Misuse Case Diagram by generating candidate misuse cases using a STRIDE matrix. Given that the number of misuse cases could be 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?
Key Deliverables You need to submit several deliverables for this assignment in the areas of feasibility (F) requirements (R), project management (PM), 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);
PM – Minutes of meetings held (template in Appendix 1);
PM – A peer assessment of the contribution of each of your colleagues to the system (this may contribute to your assessment) – template in Appendix 2;
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;
T – A test plan showing how you intend to show that your system conforms to the requirements (test case template in Appendix 3).
The System Prototype
You may choose any development system to build your prototype (e.g. Java, Visual Basic, Python, 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. Peer Assessment
Each person’s peer assessment (Word document) should be submitted to BlackBoard by the same date/time as other deliverables. Any team member who does not submit a valid peer assessment by the due date/time will receive a mark of zero (0) for the assignment.Referencing All sources of references must be cited (in text citation) and listed (end reference list). For details about referencing and the required format.(API)
You must: • Provide a zip file containing your assignment as a Word document. 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. Use the project directory structure mentioned in Teams above.
• 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: 5% Minutes (format, flow, veracity) 5% Research (understanding of problem and solution) 10% System (prototype, conformance to requirements and design) 5% Test Plan (proof of execution, connection with requirements) 5% Spelling/grammar/quality