CSP3343 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 Due date: 20th of May 2015 at 11:59pm WST 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. In Module#07, you created a Misuse Case 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: 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: MNJ 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.