CS2S562 Secure Software Development - Practical Coursework 1: Sensor Data Simulation
Practical Coursework 1
Marking and Assessment
This assignment will be marked out of 100% This assignment contributes to 60% of the total module marks.
Learning Outcomes to be assessed
1) To be able to describe the integration of security into the software development lifecycle and reflect on best practice in minimising code vulnerabilities. 2) To be able to apply principles of protection mechanisms, software security and secure design. 3) To be able to conduct static and dynamic security verification and assessment of a software application.
Provisional mark only: subject to change and / or confirmation by the Assessment Board
Assessment Task
Design and implement a piece of Console application software in C++ to simulate a smart device that could belong to The Internet of Things.
The core functional requirements are:
- The smart service provided must be based on data produced by 3 (simulated) sensors attached to the device (e.g. a weather device might register data from temperature, air pressure and wind speed sensors).
- At least one sensor's input must require some processing of the data to provide the service (e.g. a weather device might use its height above sea level to offset the measured air pressure for the height of its location - i.e. normalise it to sea level)
- At least one sensor must request an action to be performed (by an actuator) that changes the state of the device. (e.g. put the wind sensor blades into neutral when there is a severe storm to protect them from damage)
- Sensor data must be collected in some persistent storage facility - providing historical data and saving current device state. (e.g. saving a log once every 10 minutes with all sensor data plus the device's supply voltage, internal temperature, any faults, etc)
- An interface to the smart device should be simulated that provides the service and allows to manage the smart device. Users of the software should only be allowed to view and modify the data that they have permission to access. Permissions are determined by the system administrator.
The core non-functional requirements for the device are:
- It must be designed using Secure Design Principles and using two different Secure Patterns (e.g. Secure Logger and Access Control Patterns)
- It must be implemented by applying secure coding best practices (you must demonstrate in your program the use of: unsigned integers, signed integers, strings, file I/O, user keyboard I/O and pointers)Ã ¢ ¢ Document the design of the application using a UML class diagram. In this document also outline how and exactly where in your code you have applied the secure coding best practices.
A demo video is also required
- You should submit this to Panopto, guidance will be given in tutorials if you are unsure how to do this.
- The video should demonstrate the program working, it does not need to go through all the code, but you are welcome to do this if you feel it is necessary (for example, if you cannot get the program running)
Submission instructions
- If applicable, add user login details to the console information page
- Zip-up the entire Visual Studio project folder and the design document into a single zip file.
- Name the file like this: CS2S562_CW1_EnrolmentNumber_FirstName_LastName.zip (Replace the placeholders above with your enrolment number, first and last name respectively.)
- Go to the Blackboard pages of this module, select the 'Assessment' link and use the upload facility there to submit the zip file to Blackboard.
Notes about Implementing the Two Secure Patterns
You are free to implement any 2 secure patterns such as the Secure Logger, Access Control, Builder (covered in lectures) or any other suitable pattern (e.g. found in literature).
If you use the Authenticator Pattern we would be looking for:
- User Logins: several user logins implemented with usernames and passwords. The user is only granted access after entering the correct details. Support for multiple users.
- Persistence: authentication data should be stored persistently.
- Proof of ID: should be fully implemented so that no re-authentication is required during a single program run.
