[Year 12 SofDev] Security considerations influencing the design of solutions

Sat Feb 26 06:49:12 UTC 2022

Hey Bernie 
I like all that but I would not expect students to be able to program to check OATH token or active directory stuff either. But I expect them to write about such like things in their report so that it acknowledges the need.

I tell my students that they are producing a v1 not a final product and that a particular function will be implemented in v2 or v3  (or 1.0.2 or 1.3  or 2.0 )

The file permissions - again the best that they can do in a windows environment is read only BUT they still need to write about it to get top results

Two sidebar notes:

1. My key things in the SAT are being able to add, edit, delete, Load, Save, Sort, Search  - all very basic and able to be implemented easily in most languages

2. Again Kevork does a great job in maintaining these lists. I have been on these lists since he first started them and they have been a great resource. Now I am semi retired and I still like to be involved and i am ever so reluctant to let go and unsubscribe (add, delete). Unlike the fabled Mark Kelly I do not have an unending supply of Merlot.

Andrew

> On 26 Feb 2022, at 12:26 pm, MCGRATH, Bernie <Bernie.MCGRATH at kew.vic.edu.au> wrote:
> 
> Hi Sven,
>  
> Great question. Andrew has summed up the common expectations of students well. I would suggest that security needs to be a consideration at every stage of the PSM/SDLC.
>  
> For instance, if we identify a requirement in the Analysis stage that a given application requires secure authentication that integrates with our client’s authentication schema. Then at the Design stage I would suggest that we should be design the software solution such that the implementation is prescriptive. We might determine that our client uses multi-factor authentication backed by active directory and design a solution that authenticates via an OATH token or other method that active directory supports. If we left this decision for the implementation stage we might go and design a login screen where it may not be necessary because we are able to do single sign-on or we may not have identified the relevant dependencies for interaction with AD.
>  
> For many students their client will stipulate that authentication is not required/desired and I think this is okay in some instances as long it is consider and documented at the analysis stage. In this instance I still usually get students to think about the device(s) their client will use and how authentication on the device provides protection for their application data.
>  
> For data protection I ask students to think about permissions for their files and databases as well as their backup strategy. If they document something related to their intended file formats or backup strategy during U3O2 it makes U4O1 so much easier for them. At the simplest level knowing what files they need enables them to write relevant pseudocode.
>  
> Kind Regards,
>  
> Bernie
>  
>  
> From: sofdev <sofdev-bounces at edulists.com.au <mailto:sofdev-bounces at edulists.com.au>> On Behalf Of Andrew Shortell
> Sent: Saturday, 26 February 2022 12:13 PM
> To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au <mailto:sofdev at edulists.com.au>>
> Subject: Re: [Year 12 SofDev] Security considerations influencing the design of solutions
>  
> CAUTION: This email originated from outside of KEW HIGH SCHOOL. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> Hi Sven 
>  
> login - authentication
> back ups security
> safe saving
>  
> From a design point of view: Login
> The student needs to show understanding in the report BUT in the design they only need the screen(s)
> the psuedo code can just go straight through - need to demonstrate understanding of NEED for security
>  
> Also security of data - when doing delete student needs to ensure that the actual delete is not just a single click and it is gone
> usually I have students hit delete then another button appears labelled something like “this will be gone for ever. Push me to destroy the data” and another button labelled “No NO I was wrong Save me from this”
> Many students like the humour of the interface
>  
> Message boxes are so irritating that they often prevent bad moves but personally I have never liked them
>  
> Andrew
>  
> CRT a little bit
>  
>  
> 
> 
> On 26 Feb 2022, at 11:59 am, 7 <7 at 7u7.org <mailto:7 at 7u7.org>> wrote:
>  
> Hi 
>  
> Sofdev key knowledge for Unit 3 outcome 1 #14 says:
>  
> Security considerations influencing the design of Solutions, including authentication...
>  
> For authentication, I thought of hashes or checksums to verify the integrity of downloads, but this is not a design issue, is it? It would be implementation or something.
>  
> So what exactly is the study design aiming for kids to study here?
>  
> Hope someone can help
>  
> Sven
> _______________________________________________
> http://www.edulists.com.au <http://www.edulists.com.au/> - FAQ, Subscribe, Unsubscribe
> IT Software Development Mailing List 
>  
> 
> 
> IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training. _______________________________________________
> http://www.edulists.com.au <http://www.edulists.com.au/> - FAQ, Subscribe, Unsubscribe
> IT Software Development Mailing List 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://edulists.com.au/pipermail/sofdev/attachments/20220226/10d65e11/attachment-0001.htm>