Assessment Brief Module number SET10113 Module title Secure Software Development Module leader Dr Zakwan Jaroucheh Tutor with responsibility for this Assessment Dr Zakwan Jaroucheh Assessment Practical Assessment Weighting 60% of module assessment Size for assessment Approx 20 hours for the first part and approx 15 hours for the second part. Deadline of submission Your attention is drawn to the penalties for late submissions Demonstration submission (video to be uploaded): Fri 10th Apr by 15:00 Report submission: Fri 10th Apr by 15:00 Arrangements for submission This coursework is assessed in two parts, a hands-on part (with Demonstration and code submission) and a critical report. You are advised to keep your own copy of the assessment. Assessment Regulations All assessments are subject to the University Regulations. The requirements for the assessment This coursework is based on the taught academic content of the module (all LOs). Students are required to identify specific security vulnerability, assess their risk, and fix them. Also, they are required to write an essay about one topic related to the software security. See attached specification. Return of work and feedback Marks and feedback will normally be communicated via Moodle within 3 weeks of submission. Assessment criteria The code and report will be marked against the criteria laid out in the respective Marking Schedule. Note that there are no extra marks to be gained by the code submission, but it is required to ensure integrity. SET10113 – Secure Software Development Coursework – Part 1 In this coursework, you will make an assessment of a Web application from a security perspective. This includes discovering specific types of vulnerabilities, assessing their associated risk, and fixing them. You will need to implement a simple detection mechanism to report and prevent malicious attacks. In addition, you will need to do some research about one topic related to the software security. Scenario – Vulnerable Web Application You are a software engineer participating in developing a Web application called NapierUniPortal. Your development team is under pressure to deliver the MVP (minimum viable product) of the system before the deadline, and to demo that system to the management. Therefore, the focus is on delivering the required features rather than on addressing the security concerns. Now that the MVP has been built, you have been assigned the task to review the NapierUniPortal from the security perspective and work with the team to address the discovered security issues. You need to report to your manager. Things that are expected to be covered are: Access control Vulnerabilities analysis, risk assessment and vulnerability fixing (including XSS, CSFR and SQL Injection vulnerabilities) Attack detection mechanism Note that the NapierUniPortal project will be available as part of the same VM image used in the labs, in the folder /home/student/Secure-Software- Development-Module-Coursework/NapierUniPortal The NapierUniPortal Application The application is used to manage students and their courses’ enrolments. Fig. 1 illustrates the meta-model. The non-admin users should be able to register and login to the application. The admin users should be able to manage the users (students) and assign enrolments/courses to them. The implemented access control mechanism is expected to restrict access to the system features according to Table 1. Fig. 1. MetaModel Table 1. Access control Coursework – Part 1, Tasks For this part of the coursework, you are required to do the following tasks: 1. Fixing the access control implementation As you may notice, the student user is able to create or edit course programs, and the see other users’ enrolments. You need to choose an access control strategy and implement an access control mechanism to restrict the systems features according the above table. 2. Identifying and fixing XSS vulnerability(ies) – You need to conduct a manual code review and/or run some static analysis tool to determine if the application is vulnerable to XSS attack. – You need to assess the risk associated with the vulnerability(ies), score it, and translate that finding into a language understood by the project manager. – You need to fix the vulnerability, and explain your approach (e.g. from the client side, from the server side, or from both side and why). Non-Admin Admin Add/edit/delete courses Add/edit/delete enrolments Add/edit/delete programs View courses View programs View enrolments Only the current user enrolments 3. Identifying and fixing CSRF vulnerability(ies) As part of the code review process, you need to ensure that the system sends a CSRF token along with any form. Describe the issue in implementing the CSRF prevention mechanism in the Web page that allows admin users to change users’ roles, and explain your recommendation to fix that issue. 4. Identifying the linkage between vulnerabilities Let’s assume that you have identified the two potential vulnerabilities above: Explain what is the linkage between them (if any), how this linkage could be leveraged by an attacker, and what are the possible consequences. 5. Identifying and fixing SQL Injection Vulnerability(ies) – You need to conduct a manual code review and/or run some static/dynamic analysis tool to determine if the application is vulnerable to SQL Injection attack. – You need to assess the risk associated with the vulnerability(ies), score it, and translate that finding into a language understood by the project manager. – You need to fix the vulnerability(ies), and explain your approach. 6. Implementing an attack detection mechanism At this point, you may start to realise that there might be more undiscovered vulnerabilities, we don’t enough time to fix every single vulnerability, and our defences may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application. Therefore, your task is to implement a detection mechanism in the Web application to identify malicious individuals before they are able to identify any gaps in our defences. In order to limit the scope, let’s focus on detecting the SQL injection attacks. One possible way to implement the detection mechanism is by using the OWASP AppSensor Framework. 7. Providing your thoughts Your team has successfully demoed the Web application, and it is the time now for the retrospective meeting. As part of your preparation for that meeting, you need to elaborate on the following points: What went well and why? What went wrong and why? How the development process could be improved and how it should be planned in the future. Coursework – Part 2 In this part, you need to choose one of the following topics: 1. Lessons learned from well-known vulnerabilities The aim of this part is to create in your own words a detailed description of one of the widely known vulnerabilities including the vulnerability analysis, the exploitation probability and the lessons learned from the mistakes caused these vulnerabilities. You can choose one of the following vulnerabilities: CVE-2014-3566 – Poodle CVE-2014-0160 – Heartbleed CVE-2017-5638 (Equifax breach) Example of the points that could be covered in your report: What is the vulnerability, what are the affected systems, and what impact it can cause? What is the root cause? What is the associated risk and its score? How the vulnerability can be exploited? What are the lessons that could be learned from this vulnerability? Describe your recommendations in terms of the SDLC practices to avoid this type of vulnerabilities in the future. 2. Secure SDLC Methodology Many methodolog
ies have been proposed and implemented that are currently helping organizations integrate security within their SDLC. Here are some examples of these methodologies: OpenSAMM BSIMM Microsoft SDL Your task is to choose one of the methodologies, explain it in your own words, and provide your thoughts about it. Things that are expected to be covered are (this is just a non-exhaustive list of guidelines): – Detailed description of the methodology. – The promises of this methodology such as the cost savings brought about by the early integration of security within the SDLC, avoiding the costly design flaws, and increasing the long-term viability of software projects. – Its applicability/suitability for the agile development methodology. – Its implementation cost/difficulty. – The main limitations/drawbacks of that methodology. Coursework Submission 1. Look at the marking schedule detailing the evaluation criteria. Ensure you are meeting them, within the context of the scenario. 2. You will be required to demonstrate your work on Wed 25th Mar at 11:00 in C27 and Thu 26th Mar at 09:00 in C27 (at your normal practical slot in Week 12). 3. You need to submit the following deliverables by the deadline (Fri 10th Apr by 15:00): a. Report: Please submit a pdf version of your report. Do not submit Word or TEX files. The name of the pdf file should be your student number. The essay of Part 2 should be no more than 1000 words long (excluding references). The essay part will not be marked if the number of words exceed 1000 words. b. Code: Please submit one zip file containing all the files that you have changed. No need to submit the whole project along with its libraries. The zip file should be named with your matriculation number. Coursework, Part 1 – Marking schedule No Item Mark 1 Access Control – Description of the access control strategy and its implementation 3 2 XSS Vulnerability(ies) – How the vulnerability has been found (e.g. tools/manual review) 2 – Description of the associated risk, the score, and the reporting 3 – Vulnerability fixing 4 3 CSRF Vulnerability – Identification of the issue and its associated risk in the CSRF implementation 2 – Evidence of potential CSRF vulnerability (e.g. implementing a vulnerability exploitation script) 3 – Your recommendation for fixing the vulnerability 4 4 Linkage between the XSS and CSRF vulnerabilities – Explanation of the linkage and this could be leverage by an attacker 3 5 SQL Injection Vulnerability(ies) – Identification of the SQL Injection vulnerability(ies) 2 – Description of the associated risk, and the reporting 3 6 – Vulnerability fixing 4 7 Attack Detection – Description of the events and the detection points that we need to focus on. 1 – Implementing an attack detection mechanism 3 8 Retrospective thoughts – What went well 1 – What went wrong 1 – Your recommendations 1 9 Demonstration 10 Total 50 Marker’s Notes …………………………………………………………………………………………………………….. ……………………………………. …………………………………………………………………………………………………………………………………………………… …………………………………………………………………………………………………………….. ……………………………………. Coursework, Part 2 – Marking schedule No Item Mark 1 Lessons learned from well-known vulnerabilities – The vulnerability description and its root cause 10 – The associated risk 5 – How the vulnerability can be exploited 5 – What are the lessons that could be learned from this vulnerability Security mind-set: Ability to analyse and draw lessons from vulnerabilities already found in other systems. 20 – Quality of written report Quality of written English, quality of any displayed diagrams, document flow (i.e. does your work read like several sections which have little in common, or like a coherent narrative?) 5 – Extension In what ways have you extended the discussion of the given topic? This part of the mark scheme is intentionally under-specified. 5 2 Secure SDLC Methodology – The methodology description 10 – The promises of the methodology 10 – Its applicability/suitability for the agile methodology 5 – Its implementation cost/difficulty. 5 – The main limitations/drawbacks of the methodology 10 – Quality of written report Quality of written English, quality of any displayed diagrams, document flow (i.e. does your work read like several sections which have little in common, or like a coherent narrative?) 5 – Extension In what ways have you extended the discussion of the given topic? This part of the mark scheme is intentionally under-specified. 5 Total 50 Marker’s Notes …………………………………………………………………………………………………………….. ……………………………………. …………………………………………………………………………………………………………………………………………………… …………………………………………………………………………………………………………….. …………………………………….
