13 IoT Forensics
227
among citizens to collaborate and allow their devices to be Digital Witnesses they
need assurance about the protection of their personal information on such devices.
The paper shows how it is possible and feasible to have a PRoFIT-compliant Digital
Witness. The authors evaluate and confirm their approach in two cases: social
malware and warehouse registration.
13.6.2 Preparation Step with Repository
Most of the proposed models and frameworks define the need for a preparation
phase in IoT forensics. Such a phase has been suggested for other types of digital
forensics. In IoT, due to the lack of logging and local data preservation, a type of preprepared local data repository of potential evidence seems to be the most warranted.
The following papers offer some ideas on how this can be achieved.
The work in [456], from the same authors as [455], proposes a concept that
introduces a device in between the local IoT network and the home firewall
(Internet/Cloud) that provides security and forensic services. It is an end-usermanaged solution which is unusual and has its pros and cons. The device provides
standard security services like IDS/IPS, network monitoring, logging and threshold
establishment. Once something happens that causes a crossing of a set threshold
the forensic services are activated. They include data compression, parsing and
differentiation, storage, time-line creation, alerting, preparation and presentation
of results. It is an interesting idea but relies on the end user who might want to
hide certain events. Authors also mentioned issues, common with all systems that
monitor network traffic, when encryption, compression and steganography are used
on the network data. In addition, a device that sits in the path of network traffic
might become a bottleneck.
The FAIoT paper [592] formally defined IoT forensics and listed its challenges.
It proposed a forensics-aware model for the IoT infrastructures (FAIoT). The model
is supposed to help researchers focus on a specific research sub-problem of the IoT
forensics problem domain. The FAIoT consists of three parts: a secure evidence
preservation module, a secure provenance module, and access to evidence through
an API. The authors propose a centralized trusted evidence repository as a new
service available for all the IoT devices. Since the repository should handle very
large datasets, the authors propose the use of the Hadoop Distributed File System
(HDFS). To ensure a proper chain of custody by preserving the access history of
that evidence, a provenance aware file system [433] for the repository is proposed.
FAIoT could help with IoT forensics investigation but at this stage it is more a
conceptual design than a practically usable system.
One more paper that proposes a preparatory phase in order to obtain evidence
is [405]. It argues that collection of IoT devices states can enable an investigator
to create a clear picture of the events that have occurred. The authors propose a
centralized controller that can be connected to devices, controllers (hubs) and the
cloud to acquire IoT states. This controller can only read the state and cannot change
227
among citizens to collaborate and allow their devices to be Digital Witnesses they
need assurance about the protection of their personal information on such devices.
The paper shows how it is possible and feasible to have a PRoFIT-compliant Digital
Witness. The authors evaluate and confirm their approach in two cases: social
malware and warehouse registration.
13.6.2 Preparation Step with Repository
Most of the proposed models and frameworks define the need for a preparation
phase in IoT forensics. Such a phase has been suggested for other types of digital
forensics. In IoT, due to the lack of logging and local data preservation, a type of preprepared local data repository of potential evidence seems to be the most warranted.
The following papers offer some ideas on how this can be achieved.
The work in [456], from the same authors as [455], proposes a concept that
introduces a device in between the local IoT network and the home firewall
(Internet/Cloud) that provides security and forensic services. It is an end-usermanaged solution which is unusual and has its pros and cons. The device provides
standard security services like IDS/IPS, network monitoring, logging and threshold
establishment. Once something happens that causes a crossing of a set threshold
the forensic services are activated. They include data compression, parsing and
differentiation, storage, time-line creation, alerting, preparation and presentation
of results. It is an interesting idea but relies on the end user who might want to
hide certain events. Authors also mentioned issues, common with all systems that
monitor network traffic, when encryption, compression and steganography are used
on the network data. In addition, a device that sits in the path of network traffic
might become a bottleneck.
The FAIoT paper [592] formally defined IoT forensics and listed its challenges.
It proposed a forensics-aware model for the IoT infrastructures (FAIoT). The model
is supposed to help researchers focus on a specific research sub-problem of the IoT
forensics problem domain. The FAIoT consists of three parts: a secure evidence
preservation module, a secure provenance module, and access to evidence through
an API. The authors propose a centralized trusted evidence repository as a new
service available for all the IoT devices. Since the repository should handle very
large datasets, the authors propose the use of the Hadoop Distributed File System
(HDFS). To ensure a proper chain of custody by preserving the access history of
that evidence, a provenance aware file system [433] for the repository is proposed.
FAIoT could help with IoT forensics investigation but at this stage it is more a
conceptual design than a practically usable system.
One more paper that proposes a preparatory phase in order to obtain evidence
is [405]. It argues that collection of IoT devices states can enable an investigator
to create a clear picture of the events that have occurred. The authors propose a
centralized controller that can be connected to devices, controllers (hubs) and the
cloud to acquire IoT states. This controller can only read the state and cannot change