Lecture Three | Lecture Four

Often security is thought of as an afterthought, that only after a system has been designed that security implications are considered.
But to turn that on its head, security should be the forethought - that is security by design - Where a system is designed with its security implications considered at every process.
 
Though I can also see where this may go sour. Like premature optimisation of code, pre-strengthening of a system could be a bad thing.
Though that’s debatable.

This week zoomed into the security of data and information: Who can see it, who can prove it, and what is done with it.

The lecturer showed a snippet from WarGames (read abit more here), and highlighted various security features and measures to decrease unexpected events. One of these measures was a dual control system, which required two parties to partake in an action for it to be actualised. This would prevent an accidental action, but also mean that an intended action would be doubly prone to failure due to human in-action.

We also talked about data destruction - about how you would securely delete data so that it cannot be read by others.
The concept of a paper shredder was raised; a device that cuts the paper up into pieces. Although, if all of the pieces can be assembled, it is merely just a time hurdle.
For storage devices, a good idea (on a hard disk) would be to physically puncture the hard drive plattens, before crushing it even further.

The concept of work ratio was explained, which was a description of how little effort is required to gain authorised access of data, compared to how great of an effort it would be to gain unauthorised access.

This week’s case study threw a bit of a curve ball, as the analysis question didn’t at all relate to the readings.
Groups discussed primedial ways of both protecting data, and validating the integrity of data.