"A risk assessment of the Piql Services" by FFI

B.8 Sabotage

Scenario number 8

Sabotage

Scenario justification

Justification : Sabotage is a real vulnerability to any system. This could be a wire being cut, a control panel being smashed or a microchip being dislodged in a vital machine. The same vulnerability exits in the Piql Preservation Services. Purpose : The purpose of this scenario is to stress the vulnerability of the Piql system to sabotage, be it sabotage against the structural integrity of the building housing the storage facility or production site, against the piqlVault system, against the necessary machines in the production process, or against the piqlFilm directly. This particular case is a case of logical sabotage which takes place on the Piql computer which receives and processes the client data before writing. Benefit : This scenario seeks to highlight the importance of protective measures against acts of sabotage, particularly where it comes to IT security. Though the information stored with the Piql Preservation Services is immune to logical threats for most of its existence, as it is an offline medium, the risks are still present during production. The scenario is set in the geographical zone South (Southern Africa). A state actor, state X, is able to break through the computer security defences of the Piql partner and performs logical sabotage on the client information – important diplomatic correspondence. As a state actor, state X has formidable resources and skills where it comes to accessing other computer systems without authorisation. Due to the relatively strong security mechanisms put in place by Piql AS, only skilful hackers with a big support system are able to perform the kind of sabotage we are outlining here: logically tampering with the printing process so that the finished piqlFilm is missing vital information that the data owner sent in. This is only possible if state X is able to plant malware on the Piql (reception) computer which uses the physical link between that computer and the Piql I/O (production) computer to connect the two. Only then can the malware alter the checksum on both computers’ CPUs, which is necessary if state X wants to alter the client data undetected. Otherwise, the CPU on the Piql I/O computer would have picked up on the alternations to the checksum from the Piql computer’s CPU during verification. This is why this type of sabotage is so demanding: one needs to alter the checksum on both CPUs or the alterations would not be successful. Unless the data owner has backup copies of what they sent to the Piql partner, these pieces of information are lost. Scenario outline

Cause

Type of risk (Hazard/Threat)

Threat: Logical sabotage of the information while stored electronically in the Piql IT system.

141

FFI-RAPPORT 16/00707