Task Summary | My Assignment Tutor

SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 1 of 9Task SummaryYou 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 hasbeen created with. There are several possible rules that each cell or section can have, andthey 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 multiplelevels 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.ContextOne of the fundamental, core concepts of Security through Design is the separation offunctionality into different roles. This assessment follows that separation. Many programsopt 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 BRIEFSubject Code and TitleSBD403 – Secure by DesignAssessmentAssessment 3 – Executable DevelopmentIndividual/GroupIndividualLengthAs appropriateLearning OutcomesThis assessment addresses the Subject Learning Outcomes outlinedat the bottom of this document.SubmissionDue by 11:55pm AEST Sunday end of Module 12.Weighting40%Total Marks100 marks SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 2 of 9As 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, theirimportance, and your implementation of the principles covered in SBD403. The submissionmust also include a one-to-two page document outlining the various specifications OR adesign document that details justification for the appropriate architecture.This assessment will prepare you for undertaking similar projects in the industry, where youmust understand, follow, and justify your implementation of client and securityrequirements. Protection of User (or client) data within industry is of paramountimportance, and can make the difference between success and catastrophic failure of aproject.Justification and implementation are the core qualities assessed in this assignment.SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 3 of 9Task InstructionsSubmission for this assignment should be in the form of an executable application that canbe run on the university machines. The language used to develop it is up to you (discusswith the lecturer prior) but it must have an existing API to read and output to MicrosoftExcel .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 ofaccess. 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 haveaccess 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 cancreate new users, add and view data in their accounts, and can also view company-specificinformation. They can also view information on their own account, but not otherSuperusers. They cannot create Superuser accounts.Administrator:This account level cannot view user information, or create user accounts. However, theAdministrator can view Superuser information, as well as create Superuser accounts. TheAdministrator (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, andother miscellaneous data. This also includes access to the tool itself. It should also be publicto 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 notguest or administrators. This may include client details – such as names, addresses, andother private information. Client information should be visible to the specified User andSuperusers only, and not to other Clients.Company: This information is visible to users, Superusers, and Administrators. Thisinformation is only relevant to the company. This may include employment information, orcompany relevant policies, procedures, and plans.SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 4 of 9Your 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 yourtechnical skills. A well-performing example in this area would be a wellcommented, dynamic program with no visible lag or slowdown, no errors, andvery 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 principlesof Security by Design, both for the hypothetical user, and within theimplementation itself. A well-performing example in this area would be a secureprogram that does not allow users to contradict the secure principles. Thesystems 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 goodperformer in this area has many relevant features implemented. These featuresare approaching the level of a professional-level application. The features alsorespect SBD principles, and cannot be easily exploited in order to retrieveprotected data.Documentation – (30%)– The accompanying documentation for the application. A good submission for thisdocumentation not only explains the purpose of the application, but also lays outand justifies decisions made during development. The documentation includes anumber of cited, well-researched sources that add to the overall justification ofdesign decisions.SBD403_Assessment 3_Brief_Executable file_Module 12 due Page 5 of 9ReferencingReferences should be included in the accompanying document that you have created. There is nominimum amount of references however, remember that the primary component of this assessmentis 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 seemore information on referencing here: http://library.laureate.net.au/research_skills/referencingSubmission InstructionsSubmit Assessment 3 Executable Development via the Assessment link in the main navigation menuin SBD403 Secure By Design by 11:55pm AEST Sunday Module 12. The Learning Facilitator willprovide 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 9Assessment Rubric AssessmentAttributesFail(Yet to achieveminimum standard)0-49%Pass(Functional)50-64%Credit(Proficient)65-74%Distinction(Advanced)75-84%High Distinction(Exceptional)85-100%TechnicalImplementation30%Program does not run atall.ORProgram runs, but doesnot have any of therequirements outlined inthe brief.ORProgram runs, but isunable to load the sourcefile required forassessment.ORProgram runs, and is able toload the file provided.Few pieces of functionalityare present – data can beretrieved, and there are atminimum two differentaccount types present in theprogram.The program may not be ableto save to a local file, but isable to display data within thedataset itself.Accounts should not be ableto access data markedinaccessible by their accounttype.Program runs, and is able toload the file provided.The program is able to readand edit the appropriatedata within the providedfile, and there are 3different account typespresent.The program should be ableto save the data, once it hasbeen edited.Accounts should not be ableto access data markedinaccessible, and an errorwarning should inform themof this.Program runs well, and canload the provided file.The program is able to read,edit, and save theappropriate data, and thereare all 4 account typespresent.When saving, users shouldbe presented with a dialogthat allows them to choosea directory to save to.Accounts should not be ableto access data markedinaccessible, and there maybe a prompt to changeaccounts to a higher level.Program runs well, and canload the provided file.The program is able to read,edit, and save theappropriate data, and thereare all 4 account typespresent. The program mayhave additional featuresabove the aforementionedrequirements.Users can save to aspecified directory througha dialog box.Accounts retain properpermissions, request accesswhen proper, and areindependent of each otherin abilities. SBD403_Assessment 3 Brief_Executable File Module 12 due Page 7 of 9 Program runs, but is ableto access data that shouldbe inaccessible for itsaccount level.Program is implemented ina Graphical interface, ratherthan in Command line orsimply text-based.Program is implemented inan efficient, readableGraphical interface.The program isimplemented in a welldesigned graphicalinterface, approaching aprofessional level. Adherence to SBDPrinciples30%The program does notadhere to SBD principles.Issues could include: Complete lack ofdata security orrespect of cellinformation. Crossover in rolesto the detrimentof the program. Improperlyassigned roles.None of the principlesaddressed in the programhave been followed in thisassignment.Implementation may bepresent, but the systemhas obvious, fatal flawsthat prevent it from beingawarded a passing grade.The program adheres to SBDprinciples.A few principles (leastprivilege, secure architecture)may be addressed explicitly,but a large amount of theprogram may be moreinsecure.There may be overlap incertain roles (such as user andSuperuser) and account typesmay be missing.At minimum, two separateaccounts should be present,with some differentresponsibilities.There may be some flawspresent in the system, whichprevent the software frombeing awarded a higher grade.The program follows manyof the SBD principles, butperhaps not all of them.Some of these principles areaddressed explicitly, and alarge amount of theprogram is secure.There may be one or twosmall areas of overlapbetween accounts (such asSuperuser andadministrator), and 3accounts should be present– each with differentresponsibilities.At this level, there should beno easily-exploited flaws inthe system. Any moreobscure flaws must becovered in the code, as wellas in the documentationprovided.This program addresses allof the SBD principles.All of these principles areaddressed both in theoverall implementation, aswell as in the overall designof the User interface.There are no areas ofoverlap between accounts,and all 4 accounts should beimplemented, each withdifferent responsibilities.At this level, there should beno easily-exploited flaws inthe system. If any, flawsshould be noted in both thecode and thedocumentation.This program addresses allof the SBD principles.While all principles areaddressed, there areadditional secure featuresthat enable this program tobe considered at aprofessional level.There should be no areasthat are exploitable, oroverlap between accounts.Each account should remainsecure, and haveimplementation that goesabove what a traditionalstructure may implement.If there are any flaws at all(there should be nosecurity-related onesanywhere) then they shouldbe noted in bothdocumentation and code. SBD403_Assessment 3 Brief_Executable File Module 12 due Page 8 of 9 Commenting andProgrammingStandards10%The entire program lackscommenting, and thecommenting standards areinconsistent andconfusing.Comments directly hinderunderstanding of theprogram.Variables, functions, andparameters do not followa logical convention, andthe overall internalimplementation is difficultto understand from alogical standpoint.The program may lagrepeatedly, hang, or crashfrequently.Commenting is somewhatpresent, althoughcommenting standards maybe inconsistent.The comments that arepresent help to convey thegeneral idea behind thefunctionality and operationspresent in the system.Variables, functions andparameters may followseveral conventions, but theyare frequently logical. Overallimplementation is readable,and partially understandablefrom a logical standpoint.The program may lag or hanginfrequently, but crashesshould not occur.Commenting is present inthe code, and remainsrelatively consistent.Comments that are presenthelp to convey the mainideas behind functions,variables and their uses, aswell as the intendedoperations at each stage ofthe code.Variables, functions andparameters follow a singularconvention (mostly), andare – with some exceptions –largely logical. Overallimplementation is easy toread, and understand froma logical standpoint.There may be the occasionallag or hang, but theprogram should be largelystable.Commenting is present inthe code, and is consistentthroughout the entireprogram.Comments that are presentadvance the understandingof the functionality of theprogram. Areas arehighlighted and explained indetail, and include flow-onsystems present in the code.Variables, functions andparameters follow the samesingular convention, and areall similarly logical. Theoverall implementation iseasy to read andunderstand.There may be an instance ortwo of lag, but the programshould remain otherwiseflawless in stability.Commenting is present,consistent, and clearthroughout the program.Comments explain – indetail – the systems beingcovered, as well asexplaining the logic behindthe systems created – theirefficiency, etc. This shouldbe present alongside theDistinction requirements.Variables, functions, andparameters follow the sameconvention, and are allconnected logically.Implementation is clear andconcise, with efficient andprofessional use ofresources and code.The program is whollystable, and no lag orhanging is noticeable. SBD403_Assessment 3 Brief_Executable File Module 12 due Page 9 of 9 Documentation30%The documentation is notpresentORThe documentationpresented is in no wayrelevant to theassessment.OR The documentation isrelevant, but there simplyisn’t enough relevantinformation for it to beconsidered useful.Documentation has beensubmitted, and briefly detailsthe functionality of theprogram.The documentation mayoutline this functionality, butlittle justification is given forthe usage of techniques ormethods, and understandingof the necessity of thesemethods may be absent.Documentation is present,and details the functionality– and some reasoning – ofthe program.The documentation outlinesthis functionality, andexplains some of thereasoning behind thetechniques employed, andthe systems used.At this level, justificationshould be present for mostof the systems.Some explicit explanationshould be present for howthe program fits SBDguidelines as well.Documentation presentdetails the functionalitythoroughly, and providesreasoning for several areasof the program.The documentation divesinto explanation,highlighting reasoning andexploring the techniquesand systems used in detail.Justification is present, andprovided for all areas of theprogram.Explanation of how theprogram adheres to SBDguidelines is woven throughthe documentation, andhighlighted at severalstages.Documentation is present,and details bothfunctionality and reasoningacross the entire program.The documentation clearly,concisely, and accuratelydisplays the functionality ofthe entire program, as wellas providing justification ateach appropriate area as tothe overall design decisionsfor the program.The documentationhighlights its adherence toSBD guidelines, andemphasises it throughoutthe document. The following Subject Learning Outcomes are addressed in this assessmentSLO a)Demonstrate capabilities to incorporate security requirements in system specifications, design, development and testing phasesof 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.

QUALITY: 100% ORIGINAL PAPER – NO PLAGIARISM – CUSTOM PAPER

Leave a Reply

Your email address will not be published. Required fields are marked *