SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 1 of 9
Task Summary
You will be provided with a Microsoft excel .csv file. This file contains a large volume of data.
You must develop an executable that respects the permissions and rules that the file has
been created with. There are several possible rules that each cell or section can have, and
they will be detailed both below and within the sheet itself.
This program should be able to read and write to the .csv file, as well as support multiple
levels of user access (Guest, User, Superuser, and Administrator). Security information,
terms, and definitions are detailed below in the Task Instructions.
This assessment has 4 weeks allocated, and is due on the final day of the module.
Context
One of the fundamental, core concepts of Security through Design is the separation of
functionality into different roles. This assessment follows that separation. Many programs
opt to make different accounts into a ‘flow – down’ structure, where;
Users have all the permissions of guests,
‘Superusers’ have all the permissions of Users,
and administrators have full access.
| ASSESSMENT 3 BRIEF | |
| Subject Code and Title | SBD403 – Secure by Design |
| Assessment | Assessment 3 – Executable Development |
| Individual/Group | Individual |
| Length | As appropriate |
| Learning Outcomes | This assessment addresses the Subject Learning Outcomes outlined at the bottom of this document. |
| Submission | Due by 11:55pm AEST Sunday end of Module 12. |
| Weighting | 40% |
| Total Marks | 100 marks |
SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 2 of 9
As we have illustrated thus far in SBD403, this can prove problematic in certain situations.
This assessment will evaluate your understanding of the separation of specific roles, their
importance, and your implementation of the principles covered in SBD403. The submission
must also include a one-to-two page document outlining the various specifications OR a
design document that details justification for the appropriate architecture.
This assessment will prepare you for undertaking similar projects in the industry, where you
must understand, follow, and justify your implementation of client and security
requirements. Protection of User (or client) data within industry is of paramount
importance, and can make the difference between success and catastrophic failure of a
project.
Justification and implementation are the core qualities assessed in this assignment.
SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 3 of 9
Task Instructions
Submission for this assignment should be in the form of an executable application that can
be run on the university machines. The language used to develop it is up to you (discuss
with the lecturer prior) but it must have an existing API to read and output to Microsoft
Excel .csv files.
The User types are as follows:
Guest: This user is not ‘logged in’ so to speak, and should only have a minimal level of
access. At every available protected instance, the guest should have requested credentials
(such as a username or password dialog that would allow a User to sign in)
User: This user is ‘logged in’, and can be thought of as a ‘client login’. This user should have
access to their own data, but not access to any other clients’ data.
Superuser: This user is ‘logged in’, and can be thought of as a staff member. This user can
create new users, add and view data in their accounts, and can also view company-specific
information. They can also view information on their own account, but not other
Superusers. They cannot create Superuser accounts.
Administrator:
This account level cannot view user information, or create user accounts. However, the
Administrator can view Superuser information, as well as create Superuser accounts. The
Administrator (like the Superuser) can also view the Company information.
The security types are:
Public: This information is available to all users. This includes file names, sheet names, and
other miscellaneous data. This also includes access to the tool itself. It should also be public
to create a user account (which then elevates the guest to a user.)
Client / User: This information is visible to both the specific user and Superusers, but not
guest or administrators. This may include client details – such as names, addresses, and
other private information. Client information should be visible to the specified User and
Superusers only, and not to other Clients.
Company: This information is visible to users, Superusers, and Administrators. This
information is only relevant to the company. This may include employment information, or
company relevant policies, procedures, and plans.
SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 4 of 9
Your application will be marked on the following criteria:
Commenting and Programming standards – (10%)
– The quality of your documentation within the code, as well as your usage of your
technical skills. A well-performing example in this area would be a wellcommented, dynamic program with no visible lag or slowdown, no errors, and
very few to no minor issues. The program is also well commented and laid out,
with clear and concise information provided.
Adherence to SBD principles – (30%)
– This area focuses on how closely you follow, develop, and display the principles
of Security by Design, both for the hypothetical user, and within the
implementation itself. A well-performing example in this area would be a secure
program that does not allow users to contradict the secure principles. The
systems in place cannot be used to intentionally access protected data.
Technical Implementation – (30%)
– This area focuses on the technical depth of the submitted application. A good
performer in this area has many relevant features implemented. These features
are approaching the level of a professional-level application. The features also
respect SBD principles, and cannot be easily exploited in order to retrieve
protected data.
Documentation – (30%)
– The accompanying documentation for the application. A good submission for this
documentation not only explains the purpose of the application, but also lays out
and justifies decisions made during development. The documentation includes a
number of cited, well-researched sources that add to the overall justification of
design decisions.
SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 5 of 9
Referencing
References should be included in the accompanying document that you have created. There is no
minimum amount of references however, remember that the primary component of this assessment
is Justification, which makes up a large amount of the overall documentation section.
It is essential that you use the appropriate APA style for citing and referencing research. Please see
more information on referencing here: http://library.laureate.net.au/research_skills/referencing
Submission Instructions
Submit Assessment 3 Executable Development via the Assessment link in the main navigation menu
in SBD403 Secure By Design by 11:55pm AEST Sunday Module 12. The Learning Facilitator will
provide feedback via the Grade Centre in the LMS portal. Feedback can be viewed in My Grades.
SBD403_Assessment 3 Brief_Executable File Module 12 due Page 6 of 9
Assessment Rubric
| Assessment Attributes |
Fail (Yet to achieve minimum standard) 0-49% |
Pass (Functional) 50-64% |
Credit (Proficient) 65-74% |
Distinction (Advanced) 75-84% |
High Distinction (Exceptional) 85-100% |
| Technical Implementation 30% |
Program does not run at all. OR Program runs, but does not have any of the requirements outlined in the brief. OR Program runs, but is unable to load the source file required for assessment. OR |
Program runs, and is able to load the file provided. Few pieces of functionality are present – data can be retrieved, and there are at minimum two different account types present in the program. The program may not be able to save to a local file, but is able to display data within the dataset itself. Accounts should not be able to access data marked inaccessible by their account type. |
Program runs, and is able to load the file provided. The program is able to read and edit the appropriate data within the provided file, and there are 3 different account types present. The program should be able to save the data, once it has been edited. Accounts should not be able to access data marked inaccessible, and an error warning should inform them of this. |
Program runs well, and can load the provided file. The program is able to read, edit, and save the appropriate data, and there are all 4 account types present. When saving, users should be presented with a dialog that allows them to choose a directory to save to. Accounts should not be able to access data marked inaccessible, and there may be a prompt to change accounts to a higher level. |
Program runs well, and can load the provided file. The program is able to read, edit, and save the appropriate data, and there are all 4 account types present. The program may have additional features above the aforementioned requirements. Users can save to a specified directory through a dialog box. Accounts retain proper permissions, request access when proper, and are independent of each other in abilities. |
SBD403_Assessment 3 Brief_Executable File Module 12 due Page 7 of 9
| Program runs, but is able to access data that should be inaccessible for its account level. |
Program is implemented in a Graphical interface, rather than in Command line or simply text-based. |
Program is implemented in an efficient, readable Graphical interface. |
The program is implemented in a well designed graphical interface, approaching a professional level. |
| Adherence to SBD Principles 30% |
The program does not adhere to SBD principles. Issues could include: Complete lack of data security or respect of cell information. Crossover in roles to the detriment of the program. Improperly assigned roles. None of the principles addressed in the program have been followed in this assignment. Implementation may be present, but the system has obvious, fatal flaws that prevent it from being awarded a passing grade. |
The program adheres to SBD principles. A few principles (least privilege, secure architecture) may be addressed explicitly, but a large amount of the program may be more insecure. There may be overlap in certain roles (such as user and Superuser) and account types may be missing. At minimum, two separate accounts should be present, with some different responsibilities. There may be some flaws present in the system, which prevent the software from being awarded a higher grade. |
The program follows many of the SBD principles, but perhaps not all of them. Some of these principles are addressed explicitly, and a large amount of the program is secure. There may be one or two small areas of overlap between accounts (such as Superuser and administrator), and 3 accounts should be present – each with different responsibilities. At this level, there should be no easily-exploited flaws in the system. Any more obscure flaws must be covered in the code, as well as in the documentation provided. |
This program addresses all of the SBD principles. All of these principles are addressed both in the overall implementation, as well as in the overall design of the User interface. There are no areas of overlap between accounts, and all 4 accounts should be implemented, each with different responsibilities. At this level, there should be no easily-exploited flaws in the system. If any, flaws should be noted in both the code and the documentation. |
This program addresses all of the SBD principles. While all principles are addressed, there are additional secure features that enable this program to be considered at a professional level. There should be no areas that are exploitable, or overlap between accounts. Each account should remain secure, and have implementation that goes above what a traditional structure may implement. If there are any flaws at all (there should be no security-related ones anywhere) then they should be noted in both documentation and code. |
SBD403_Assessment 3 Brief_Executable File Module 12 due Page 8 of 9
| Commenting and Programming Standards 10% |
The entire program lacks commenting, and the commenting standards are inconsistent and confusing. Comments directly hinder understanding of the program. Variables, functions, and parameters do not follow a logical convention, and the overall internal implementation is difficult to understand from a logical standpoint. The program may lag repeatedly, hang, or crash frequently. |
Commenting is somewhat present, although commenting standards may be inconsistent. The comments that are present help to convey the general idea behind the functionality and operations present in the system. Variables, functions and parameters may follow several conventions, but they are frequently logical. Overall implementation is readable, and partially understandable from a logical standpoint. The program may lag or hang infrequently, but crashes should not occur. |
Commenting is present in the code, and remains relatively consistent. Comments that are present help to convey the main ideas behind functions, variables and their uses, as well as the intended operations at each stage of the code. Variables, functions and parameters follow a singular convention (mostly), and are – with some exceptions – largely logical. Overall implementation is easy to read, and understand from a logical standpoint. There may be the occasional lag or hang, but the program should be largely stable. |
Commenting is present in the code, and is consistent throughout the entire program. Comments that are present advance the understanding of the functionality of the program. Areas are highlighted and explained in detail, and include flow-on systems present in the code. Variables, functions and parameters follow the same singular convention, and are all similarly logical. The overall implementation is easy to read and understand. There may be an instance or two of lag, but the program should remain otherwise flawless in stability. |
Commenting is present, consistent, and clear throughout the program. Comments explain – in detail – the systems being covered, as well as explaining the logic behind the systems created – their efficiency, etc. This should be present alongside the Distinction requirements. Variables, functions, and parameters follow the same convention, and are all connected logically. Implementation is clear and concise, with efficient and professional use of resources and code. The program is wholly stable, and no lag or hanging is noticeable. |
SBD403_Assessment 3 Brief_Executable File Module 12 due Page 9 of 9
| Documentation 30% |
The documentation is not present OR The documentation presented is in no way relevant to the assessment. OR The documentation is relevant, but there simply isn’t enough relevant information for it to be considered useful. |
Documentation has been submitted, and briefly details the functionality of the program. The documentation may outline this functionality, but little justification is given for the usage of techniques or methods, and understanding of the necessity of these methods may be absent. |
Documentation is present, and details the functionality – and some reasoning – of the program. The documentation outlines this functionality, and explains some of the reasoning behind the techniques employed, and the systems used. At this level, justification should be present for most of the systems. Some explicit explanation should be present for how the program fits SBD guidelines as well. |
Documentation present details the functionality thoroughly, and provides reasoning for several areas of the program. The documentation dives into explanation, highlighting reasoning and exploring the techniques and systems used in detail. Justification is present, and provided for all areas of the program. Explanation of how the program adheres to SBD guidelines is woven through the documentation, and highlighted at several stages. |
Documentation is present, and details both functionality and reasoning across the entire program. The documentation clearly, concisely, and accurately displays the functionality of the entire program, as well as providing justification at each appropriate area as to the overall design decisions for the program. The documentation highlights its adherence to SBD guidelines, and emphasises it throughout the document. |
| The following Subject Learning Outcomes are addressed in this assessment | |
| SLO a) | Demonstrate capabilities to incorporate security requirements in system specifications, design, development and testing phases of software development. |
| SLO b) | Administer implementation of security controls, security risk mitigation approaches, and secure design architecture principles. |
| SLO c) | Explain Secure Development Lifecycle models and identify appropriate model for a given situation. |
| SLO d) | Assess the maturity of secure systems development in the IT work environment. |
| SLO e) | Apply Security by Design industry standard principles in real time systems development. |