A Risk Assessment of Piql Services by FFI

the use of a malicious transmitter, then, a threat actor could either jam the signals completely and halt all operations, or, if the threat actor is able to break through the security protocol protecting the radio signals, their contents can be altered to make the robots move about haphazardly all over the piqlVault grid. We mentioned in section 5.5.3 that the security protocol used by the radio signals is a protocol of the supplier of the AutoStore® system’s own design, the contents of which FFI has not been privy to. 44 The fact that the protocol is not standard, i.e. that its contents are unknown, amounts to a certain degree of security, but it is a weak form of security. As FFI does not know its contents, we cannot assume it is impossible to breach. Having outlined the relatively few weaknesses to the IT security architecture of the Piql Preservation Services, we now turn to a discussion of the importance of a sound security architecture along three different viewpoints: that of the client, of Piql AS, and the supplier of the piqlVault system. The consequences of the potential loss of information is different for the three, making the risks associated with the loss vary in severity. The client or user of the Piql Preservation Services is perhaps the one which stands to lose the most should something happen to the CIA of their information stored. They are also affected should something happen to all three types of data stored with the Piql Preservation Services: the client data (content data), metadata and unique film reel IDs. 45 Piql AS must strive to earn the trust of the clients in the service that they provide, meaning that the client can trust that Piql AS’ IT security architecture is up to par, and they can trust Piql AS to make sound judgements when it comes to the suppliers and providers they choose to outsource parts of their service to. If the clients cannot trust the functionality or security of the Piql IT security architecture on these issues, several things can happen which would have very negative consequences for them. First, if Piql AS’ computer security fails, the clients can potentially lose their content data, or the metadata which allows this data to be located, or the reel ID which allows the physical film to be retrieved. This would affect the CIA of the data. Second, if something fails in the IT security architecture of the supplier of the piqlVault, it will be impossible to find a given reel exactly when needed. This would affect the availability of the data. The client is thus vulnerable to mistakes in both the internal Piql IT system and the external piqlVault IT system. For Piql AS themselves, the risks are similar to that of the clients, as they also are affected if something happens to all three types of data. If there is a security breach in the piqlVault IT system which affects the reel IDs stored there, and they are then unable to extract the piqlFilm, this reflects negatively on Piql AS’ business image. As a result, Piql AS may lose trust from their existing and potential new clients, which, as mentioned above, is vital to keep. Though Piql AS must maintain a good relationship with their clients in this capacity, they must also be sceptical of what the clients might bring into the Piql IT system, either wittingly or unwittingly. Should a threat actor posing as a client, or threat actors in general, be able to ingest malware in the Piql IT system through the Front-End service, this could negatively affect both the content data and the metadata.

44 The information regarding the security protocol designed by Hatteland was given during a meeting with Terje Skjølberg, Sales Manager at Element Logic AS, on 11.11.15. 45 See figure 5.3 in chapter 5 as a reference.

85

FFI-RAPPORT 16/00707