Secure Storage Model for Digital Forensic Readiness

Securing digital evidence is a key factor that contributes to evidence admissibility during digital forensic investigations, particularly in establishing the chain of custody of digital evidence. However, not enough is done to ensure that the environment and access to the evidence are secure. Attackers can go to extreme lengths to cover up their tracks, which is a serious concern to digital forensics – particularly digital forensic readiness. If an attacker gains access to the location where evidence is stored, they could easily alter the evidence (if not remove it altogether). Even though integrity checks can be performed to ensure that the evidence is sound, the collected evidence may contain sensitive information that an attacker can easily use for other forms of attack. To this end, this paper proposes a model for securely storing digital evidence captured pre- and post-incident to achieve reactive forensics. Various components were considered, such as integrity checks, environment sandboxing, strong encryption, two-factor authentication, as well as unique random file naming. A proof-of-concept tool was developed to realize this model and to prove its validity. A series of tests were conducted to check for system security, performance, and requirements validation, Overall, the results obtained showed that, with minimal effort, securing forensic artefacts is a relatively inexpensive and reliable feat. This paper aims to standardize evidence storage, practice high security standards, as well as remove the need to create new systems that achieve the same purpose.


I. INTRODUCTION
The upsurge in cyber-attacks and data exploitation has made the need for digital investigations paramount [1]- [3]. Standardization and adherence to best practices have become essential to ensure the least amount of human error causing inadmissible evidence [4], [5]. Forensic artefacts are very important when it comes to investigation and litigation, as they provide the details of an incident [6], [7]. When forensic artefacts are presented in a court of law, they are subject to scrutiny and require verification and cross-examination [8], [9]. Digital evidence needs to preserve the CIA triad [10], namely confidentiality, integrity, and availability. Confidentiality of digital evidence must be ensured because the evidence may contain sensitive information such as credit card information or other personal identifiers [10]. To protect the evidence, strict access control needs to be maintained, and/or an encryption scheme has to be used to ensure that only an The associate editor coordinating the review of this manuscript and approving it for publication was Ramakrishnan Srinivasan.
investigator or authorized parties have access to the digital evidence [11]. Ensuring the integrity of the digital evidence is one of the most important processes of any digital investigation, as an investigator needs to prove that the evidence was not fabricated or tampered with in any way. To achieve this, a forensic copy of the original evidence, as well as the software logs and the chain of custody, is kept [12]. The process followed by the investigator to acquire the evidence also needs to be documented. The forensic hash of the evidence needs to be calculated at different times -during the time of collection and storage -to ensure that the original evidence was not changed, and the process followed by the investigator was sound and did not modify the evidence in any way. Therefore, a secure storage model is needed to improve the investigation process and safeguard any sensitive information collected. The same problem affects digital forensic readiness systems, whether large or small organizations or even individual people. These systems collect evidence proactively, therefore, evidence preservation and storage processes are vital to ensure that evidence is valid and authentic.
The next section provides some background on digital forensic readiness and encryption. Thereafter, the proposed process model is explained, detailing each of the processes involved, followed by the proof-of-concept prototype tool that was developed. Next, the tool was evaluated in terms of usefulness and performance, before the paper is concluded.

II. BACKGROUND
Digital forensic readiness (DFR) as defined by Tan [13] is the ability of an organization to maximize its evidence collection mechanisms whilst aiming to reduce the costs involved in collection [13]. Therefore, to achieve DFR, potential digital evidence collection needs to take place before an incident can occur. DFR is a proactive approach to digital forensics that is more robust and cost-effective in the long term. To implement DFR in any organization, its business operations need to be well defined and understood, as they may differ from organization to organization. The ISO/IEC 27043 international standard [14] defines a more robust guideline about the traditional digital investigation processes as well as high-level readiness processes. This encompasses five processes, namely readiness, initialization, acquisition, investigative, and concurrent processes [14]. It also ties in with the investigation lifecycle as shown in Figure 1, which consists of planning, acquisition, preservation, analysis, reporting, dissemination, and chain of custody. Most research focuses on the acquisition and analysis of evidence; however, little is done about the preservation of evidence and its integrity. No comprehensive models or guidelines are defined for evidence integrity preservation, specifically in digital forensic readiness. Although ISO/IEC 27037 [15] contains a clause on evidence preservation that outlines general guidelines on the physical storage and preservation of evidence, it is not sufficient for comprehensive evidence integrity preservation in terms of storage security. Most existing research focuses on using encryption to secure data that is being stored [16]- [19]. Due to the nature of the data stored, most common encryption focuses on symmetric encryption which means that there is a single encryption key that also serves as the decryption key [11], [20]. AES (Advanced Encryption Standard) is the dominant (standard) encryption scheme used by cloud and enterprise platforms because of its speed and performance [11], [20], [21]. However, if the decryption key is not stored securely, it leaves the encrypted data still vulnerable to be stolen or misused. At the time of writing this paper, no model or framework provides the best practice on how to securely store data and ensure its integrity in a digital forensic environment. In digital forensics, it is essential that the integrity of the data remains intact to make it reputable and admissible in a court of law [22], [23]. In DFR, potential digital evidence (PDE) is defined as information or data stored or transmitted in binary form, which has not yet been determined to be relevant to the investigation (through the process of examination and analysis) [14]. Only after the PDE has been positively identified as evidence, it is accepted as digital evidence. To mimic a more real-world application of PDE with DFR in mind all references to PDE are made to simplify the explanations. PDE can be seen as small artefacts (not large disk dumps) that may hold important or sensitive data. Since PDE could be used to incriminate an individual, it needs to maintain its integrity and authenticity to be admissible. Therefore, some processes must be in place to ensure the correct steps and processes are followed, to ensure the integrity of the PDE. To date, no processes or models exist to address the integrity constraint, especially with DFR. There are also no tools that focus solely on the storage of PDE. On the contrary, these tools focus on the extraction and collection of PDE, and it is up to the investigator or organization to safeguard and preserve the PDE according to their policies [24].
Anti-forensics is cumbersome in cloud environments, and attackers are always trying to cover up their footprints [25]. They usually move laterally in a network to find vulnerabilities and exploit them by removing any traces of the attack from the logs and computers. Therefore, having a secure environment is important, and sensitive information should be secured and encrypted. While several cloud service providers do provide encryption, it often comes at a huge cost or additional overhead and attackers can easily bypass the service providers' countermeasures by targeting less secure Virtual Machines (VMs) [25]. While several studies have explored readiness in the cloud [15], [26]- [28], the more fundamental problem is providing secure storage for the PDE artifacts that are collected. To that end, this research developed a secure storage system to store digitally forensic ready PDE artifacts in a forensically sound manner. The next section explains the developed process model, namely Secure Readiness Storage (SecureRS), in accordance with security standards and the digital forensic investigation lifecycle.

III. SecureRS PROCESS MODEL
To address the lack of an automated mechanism for preserving evidence and maintaining integrity, a model was developed targeting the various security and forensic aspects during the investigation lifecycle. This model is an improvement of the authors' previous work [29]. The SecureRS model ties in with some of the readiness processes addressed in ISO/IEC 27043 [14]. For instance, the planning process group of ISO/IEC 27043 [14] involves the ''Planning preincident collection, storage, and handling of data representing potential digital evidence'' [14]. It discusses the criteria of collection and storage, but nothing is provided on how storage and evidence preservation should be carried out. Therefore, the proposed model consists of four high-level processes, namely data ingestion, forensic soundness assurance, PDE storage, and forensic soundness verification (see Figure 2). The data ingestion process acts as a mechanism for data to be fed into the secure system. It ensures a controlled environment because it is common practice to make use of a Web API. The SecureRS model makes use of a Representational State Transfer (REST) API to allow a multitude of data ingestion formats as well as a consistent endpoint with a lower bandwidth than other API types. When questioning the integrity of a storage engine or system, it is important to understand what processes the data undergoes. To ensure that the system or a user does not modify any information, integrity checksums are calculated before and after to ensure nothing was changed. Since the collection of evidence does not fall within the scope of the current research, it is assumed that data collected and sent to the model is forensically sound already. The PDE storage process is built for security, based on the CIA triad. During the final stage -the verification process -the integrity before and after storage is checked to ensure nothing has been modified, thus ensuring forensic soundness. The four processes followed in the model are discussed next in more detail. The four phases are outlined, and how each aids the security as well as forensic aspects that a piece of evidence needs to possess for the evidence to be admissible in a court of law.

A. DATA INGESTION PROCESS
The data ingestion process comprises seven steps as seen in Figure 2. This process starts with Potential Digital Evidence (PDE) (i.e., small artefacts or pieces of data that may have forensic value) and the PDE's metadata, which helps the system identify the origin and purpose of the PDE. The collection of PDE is not considered part of the scope of this research, as it is a vast research area on its own and only the storage processes are explored in this research. PDE metadata that is needed includes the user or origin, IP address, computer name, rank, file name, and hash checksum. This information is necessary, particularly in an organization, to know where the PDE originates from and to manage the data.
The next stage involves using a transport protocol so that the data from the origin can be received by the system. Different protocols are available; however, the most used and common transport protocol, which is the foundation of the internet, is TCP/IP. Using the TCP/IP method for data transport makes it reliable for data ingestions. The transport method also needs to be secured to prevent eavesdroppers or man-in-the-middle attacks. The transport encryption layer that is chosen involves making use of the secure socket layer (SSL). This SSL layer, coupled with TCP/IP together with HTTP and its application layer protocol, provides HTTPS. An HTTPS connection provides a secure means of communication that is encrypted between two parties, namely the client and server. Using TLS (Transport Layer Security)/SSL is an industry best practice and standard as a move towards a more secure internet. If data is intercepted (by a man-in-the-middle attack, for example), it will be potentially unusable to an attacker as all data would be encrypted [30]. In the SecureRS model, it was decided to make use of a web REST API for data transfer and logic processing. Web APIs are portable and the most modular method of easily ingesting data, requiring minimal effort to set up. To make the ingestion process faster and more standardized, a known standardized API endpoint (similar to a URL path) is exposed on the webserver for data to be ingested. Furthermore, allowing only the HTTP POST method ensures that data remains secure and encrypted in the body of the request. This method also allows large files to be sent -as opposed to the HTTP GET method. The data transferred in the POST method prevents the webserver from logging the request information as what can be seen from GET requests in server logs. Such webserver logging could prove harmful as the GET request parameters would be passed through the URL, which may contain sensitive information. For simplicity, the data format that is supported for ingestion is form data, as this allows both textual information and file upload.
To ensure that only authorized parties can push data to the storage engine, an API key and prefix key are generated through a system admin account for each device/user within the organization. The API key is hashed before it is stored, therefore, the key is only displayed and available at the time it is created. The API prefix furthermore serves as a unique identifier. The API token is used in conjunction with the prefix key to add another layer of security. The prefix key and API key are then verified and, once successful, the metadata is sanitized. This sanitization removes any malicious data, SQL, or JS injections from cross-site scripting (XSS) (from the metadata only). The PDE itself is treated as a read-only file and not displayed in the system, thereby removing the need to perform any sanitization, and so ensuring the integrity of the PDE. The metadata sanitization is performed to ensure that no exploits and vulnerabilities are exposed by the system itself and to conform to best web security practices. The metadata collected about the PDE is shown in Figure 3, which is kept separate from the PDE. After data has been sanitized to ensure system security, the next process is data validation. The validation process ensures that the data expected is the data received and that the data is parsed with the correct data structure and format. Once the data has been successfully validated, it gets sent on to the next phase for forensic assurance.

B. FORENSIC SOUNDNESS ASSURANCE PROCESS
For digital evidence to be forensically sound and to be held admissible in a court of law, its collection, storing, and analysis must be documented in a legally acceptable manner [16], [17], [31]. Therefore, assurance is needed to prove that the evidence has not been corrupted or destroyed during the investigation process, whether by accident or intentionally. This process furthermore generates the relevant information (such as hash checksums) to prove the forensic soundness of the collected data once the data has been received. Since this system is simply a storage engine, it is assumed that the data that was collected before the system ingestion was forensically sound. However, since nothing has been written to disk or the database as yet, this process is done in-memory. This is to ensure the data was not modified while being written to the disk, whether by another process or due to human error.
The ability to ensure forensic soundness is achieved by taking an in-memory hash (H1) of the PDE using an MD5 hash algorithm as an integrity measure. It is then compared to the metadata md5sum field received from the HTTP POST request to ensure the data sent by the origin is indeed what is received by the API. This serves a dual purpose, namely, to ensure data was not lost or intercepted along the way, and to maintain the integrity of the PDE. Although MD5 is typically seen as an insecure hashing algorithm, it is very suitable as an integrity measure due to its efficiency in computing a hash as opposed to securing hashing algorithms. The next step is to secure the PDE by performing symmetric key encryption. This is to ensure that data stored on the disk is not subject to being read by another system or person, as a PDE file could contain sensitive information. After PDE encryption, another hash (H2) is generated of the encrypted PDE. This new hash is used as input to the process of forensic soundness verification. The next process involves the storage of the encrypted PDE to disk.

C. PDE STORAGE PROCESS
The storage process starts by taking the encrypted PDE from memory and generating a unique filename of 60 alphanumeric characters to ensure that the system is immune to URL manipulation. This unique filename prevents a PDE from being easily identified by a system admin since there would just be random encrypted files. The PDE is stored to disk with read-only permissions on the file system, such that no process or human error can accidentally change it, thereby violating the PDE's integrity. After setting the permissions, the file is now safely stored in the secure storage within the protected directory in the virtual environment, ready for verification and integrity confirmation. Changing the extrinsic metadata of the PDE (such as the file name or permissions) does not change the data of the PDE itself, hence the hash and integrity remain intact [18], [32]. Details of the forensic verification and assurance process are presented next.

D. FORENSIC SOUNDNESS VERIFICATION PROCESS
This process involves ensuring that the integrity of the evidence is indeed intact and unaltered, thus adhering to standard forensic practice. To ensure that the integrity of the stored PDE remains intact, a hash (H3) is computed on the stored and encrypted PDE. This adds a verification layer which ensures that the forensic soundness of the PDE is maintained from the point of encryption to the storage of the PDE.
To ensure forensic soundness, the in-memory hash of the encrypted PDE (H2) is then compared to (H3). If H2 and H3 are the same, no deliberate or accidental manipulation of the PDE occurred, and it is verified as forensically sound. When the verification was successful, the entry is inserted into the database for reference. This entry contains the metadata of the PDE itself, such as the location of the stored PDE, and not the actual PDE itself. Storing a reference to a file location in a database -as opposed to storing the entire fileconforms to best practices, due to the inefficiency of storing binary data in a relational database [19]. This also makes it difficult for an attacker as it expands the attack vector by abstracting the PDE itself from the metadata. For example, if an attacker gets unauthorized access to the database, the only information that can be extracted is the metadata which on its own does not give enough information for malicious intent. To further protect the entry in the database, the original hash and PDE location are encrypted by the system, adding a layer of security, and thereby making it impossible for an attacker or system admin to relate PDE to its metadata outside the system. If the hashes in the verification process are not identical, it can be assumed that external modification could have occurred or that something unconventional originated, such as electricity spikes or bad disk sectors, thus resulting in invalidating the forensic soundness. Such an instance would be rare and uncontrolled, and a system admin would be notified to manually investigate what the cause could have been. This investigation is a manual process, as the violation would have occurred under unknown circumstances and was not part of the scope of this research.

E. PDE DOWNLOAD PROCESS
The downloading of PDE is also an important aspect of the system to ensure that only authorized parties are allowed to download the PDE. To protect the PDE, the system first verifies the session of the logged-in user and then prompts the user for the 2FA pin. Once the pin and the session have been successfully validated, then only does the system decrypt the PDE. Thereafter, another hash (H4) is generated and then compared to the original hash (H1) to ensure that nothing has happened to the PDE during storage as well as to verify the integrity of the forensic copy that will be downloaded by the investigator. In the event the hashes do not match, the system will alert the administrator to manually investigate the issue. Therefore, the downloaded PDE that the investigator will receive is safe and its integrity is maintained from ingestion into the system to download, thereby minimizing any human error that can occur as well as serving as a secure backup to PDE. The hash is also given to the investigator if further corroboration or verification is needed. The next section discusses the reference implementation of the proposed SecureRS model.

IV. SecureRS TOOL
To show that the proposed SecureRS process model (see Figure 2) would work and is valid, a proof-of-concept tool was created using agile software development methodology [33]. The requirement specification and usability are the core functions for any software following agile principles. To ensure that the proposed SecureRS proof-of-concept tool adheres to standards and good software practice and principles, the tool was tested using the testing processes of the Computer Forensics Tool Testing (CFTT) program [34] of the National Institute of Standards and Technology (NIST) [35].

A. SecureRS SYSTEM REQUIREMENTS SPECIFICATION
The system requirements are divided into two categories, namely secure storage core requirements (SS-CR) (see Table 1) and secure storage optional requirements (SS-OR) (see Table 2). For example, in Table 1 the label column provides a reference number which will be used in Section C. The description, on the other hand, provides the requirements for the tool, for example, SS-CR-01 says that the tool shall ingest data from an API endpoint, which specifies the functionality of the tool.

B. SecureRS SYSTEM IMPLEMENTATION
Now that the requirements have been defined, the tool was implemented using a modular approach and applying agile principles. The programming language that was chosen to implement this tool was Python, due to its flexibility and built-in frameworks and libraries. In order to make a web platform and allow easy management, Django web framework [36] was chosen. The tool uses Django REST framework [37] as it provides a mechanism for applying RESTful API functionality fairly easily. This framework furthermore provides authentication based on a secure API key, which is created from the admin panel on the system, allowing easy management and revoking of keys. Each key is unique and serves as an authentication mechanism for making an HTTP POST request to the API endpoint. The security sanitization process followed uses Django's default security middleware as well as custom sanitization middleware to remove special characters and tags from the metadata. The different middlewares used include: SecurityMiddleware, SessionMiddleware, CsrfViewMiddleware, AuthenticationMiddleware, XFrameOptionsMiddleware, OTPMiddleware, SessionSecu-rityMiddleware. The tool also made use of encrypted fields in Django models to further protect the sensitive metadata. This was done to prevent the misuse of data due to unauthorized access or misconduct.
To secure the PDE file, a Django-encrypted file field was chosen, which uses the Fernet encryption scheme [38]. The latter is a symmetric key algorithm that makes sure that the encrypted message cannot be manipulated, brute-forced, or read without a password key. This key is URL safe encoded with base64 so that any reserved, unprintable, or non-ASCII characters are replaced. It ensures that no errors occur when handling the keys that an attacker could potentially exploit. Fernet also makes use of advanced encryption standard (AES) 128-bit cipher block chaining (CBC) mode and public-key cryptographic standards number 7 (PKCS7) padding. This means that the cipher is in multiples of 128-bits, with PKCS7 padding to fill the remaining bits. The password key makes use of a hash-based message authentication code (HMAC). The HMAC serves a dual purpose and simultaneously verifies the integrity and authenticity of a message. This is done to ensure better security, as HMAC was used in conjunction with a simple hashing algorithm (SHA) of 256 bits (SHA256) [38]. All symmetric encryption keys are on the system itself, either as a setting in the Django configuration or managed by the Django framework itself.
Portability was one of the contributing factors for making use of Docker [39] (a containerized approach to hosting services). Using Docker makes the system easily scalable as well as platform independent, and it provides load balancing. The high-level flow chart showing the lifecycle of SecureRS is shown in Figure 4. The lifecycle starts with ensuring that the system is installed successfully, and subsequently initializes the system. The setup does not require much besides creating a superuser (a feature of the Django framework) and it provides admin functionality such as creating users, setting access roles, creating API keys, etc. Once the system has been initialized, the next step is account creation, which involves two-factor authentication (2FA), and the creation of API keys. From a design perspective, it was decided that (for more security and traceability) only an admin user can create users and API keys. The 2FA system catered for email, SMS, and YubiKey [40]. 2FA is required for logging in and also to ensure safe download of a PDE file. Token generators make use of the timebased one-time pin (TOTP) algorithm [41] that generates 6-8 unique digits based on the current time and some secret key that is added when the account is registered. By design, these tokens are regenerated every 30 seconds to prevent attackers from brute-forcing the token or launching phishing attacks. Backup tokens are also enabled if devices used for TOTP are not available. These backup tokens can only be used once, thereby allowing recovery and security. User credentials are stored using Django's default password field, which uses PBKDF2 with strong SHA 256-bit hashing and a random salt [36]. This password stretching mechanism is recommended by NIST [35]. When an investigator selects a PDE file to be investigated further, several checks occur. Firstly, the session is checked to see if it is still active and if the logged-in user has the required permissions. This is achieved by verifying that the inactivity time of the user has not passed the threshold and that 2FA is enabled. A user is warned after three minutes of inactivity and consequently logged out after ten minutes of inactivity. These thresholds are configurable in the settings. After the session and 2FA process have been successfully validated, the PDE will be decrypted by the system and available for the investigator to download for further manual investigation to corroborate findings. The implementation of SecureRS platform can be found at: https://github.com/AvinashSingh786/SecureRS

C. SECURE STORAGE VALIDATION
This section details the testing of the tool in terms of its implementation correctness and determines if the tool has met the requirements defined in Section A. This complies with the NIST validation cycle and is structured as follows: secure storage core test assertions (SS-CA) (see Table 3), secure storage test cases (SS-TC) (see Table 4), and the secure storage compliance matrix (SSCM) (see Table 5).
A compliance matrix simply states the requirements, the test case(s) that tested the specific requirement, and the result, which is a core test assertion or a manual check. For example, if a core test assertion was met, that test assertion is specified in the result column. However, if a manual check was performed, it is indicated with '--check--', indicating that the check result is compliant. The compliance matrix determines if the tool met the requirements and is compliant. The compliance matrix for secure storage is presented in Table 5. The compliance matrix confirms that the results from the test assertions have been fulfilled, therefore implying that all the requirements defined have been met and are successfully tested and compliant. Now that the tool has been validated and satisfies the NIST CFTT [34], the next phase is to evaluate the tool to determine the performance of the system and its model.

V. SecureRS PERFORMANCE EVALUATION
Given that the prototype system has been validated through the NIST CFTT [34], it is important to gauge the performance of the system. To determine the performance of the system,  several factors were considered -the speed of data ingestion; the amount of data ingested; processor and memory utilization; the time until the data was stored. Table 6 shows the  system specification that was used to benchmark the application of SecureRS. Organizations typically would run the system on the same network; therefore, to rule out network speeds and latency, the system was tested in ideal circumstances where the data ingested was sourced from the same host, i.e., 'localhost'.
It is also important to determine a baseline of the SecureRS systems memory and processor utilization so that when data is being ingested, the overall performance difference can be determined. Table 7 shows the idle baseline values for the system. From this table, an approximate value of 36 MB of memory utilization and about 1% of processor utilization are used, showing that when no data is being ingested and stored, the system does not utilize many resources.
The testing phase consisted of a 1 GB PDE and 100 MB payload that contained methodically generated ASCII data. In DFR, the size of a PDE is context-dependent and relies on the kind of data that is stored. It is quite difficult to get an accurate representation of the maximum size of a PDE payload. However, this research is aimed at DFR, so large PDE files would be extremely rare. To that end, tests were performed on the perceived worst-case and best-case size of a PDE to determine the effects on performance. For this study, the worst case chosen was a large payload of 1 GB and the average case was 100 MB. These values were chosen based on some existing DFR literature [42]- [45]. To make the performance evaluation as comprehensive as possible, the system was tested under various circumstances, namely single, multiple, and concurrent HTTP requests. In the case of single requests, only one HTTP POST request was made, and the performance indicators were observed. Multiple HTTP requests were sent synchronously, meaning that after one request was sent, another was initiated. To get an average, a set of 10 requests was made. The reason for testing synchronously was to determine the implications of the hashing process conducted by the system and to see if it would be able to handle the load without using many resources. The final evaluation was based on sending concurrent requests to the system to see how its performance would be affected and to show the robustness of the system. Table 8 shows the performance of a single request with a 1 GB PDE payload. The results in parentheses show the performance at the time of hashing and encryption. From these results, an average of 3.6% processor utilization was used while 19.6% was used during hashing and encryption. We observed a higher memory utilization during hashing and encryption, apparently because parts of the file must be read into memory before it can be encrypted and hashed. Overall, for the worst case of a 1 GB PDE, a total time of 36.76s was observed to ingest, validate, secure, and store. Where an investigator would perform the process manually, it would take roughly 2m 11s, based on one manual attempt conducted by the authors.
When comparing Table 8 and Table 9, there is not much difference in the performance. This was expected since the requests were sent synchronously. An average time of 36.21s was observed from the time the PDE was sent to the storage engine until the time it was successfully stored following the forensic assurance processes. Table 10 shows the performance for concurrent requests, and a slight decrease in ingestion speed and an increase in CPU usage could be observed. This was expected, as requests were performed in parallel. Table 11 to Table 13 show that where a smaller PDE was used, a corresponding insignificant difference in performance was observed. This implies that the system can still perform  well under high load without a significant time utilization; however, as expected, it does consume more resources. The bottleneck occurs when hashing and encryption are performed, since this is a computationally expensive task. Even though during the concurrent requests there was more processor and memory utilization, the system still performed well given the process each PDE had to undergo. Results from Table 8 to Table 13 clearly show that SecureRS can still ingest data relatively well and is able to handle the load without much resource usage. Moreover, forensic soundness is ensured through the defined processes.
To further illustrate the effectiveness of SecureRS, a graphical depiction of Table 8 to 13 is illustrated in Figure 5. From this figure, the observed speed of data ingestion remained relatively consistent with relation to the PDE size and operation. The memory consumption remained somewhat consistent over the tests excluding the encryption state. The concurrent processor utilization for both the 1GB and 100MB PDE  remained in a same range between 14-16% whereas the time was significantly better with the larger PDE. This is on the assumption that 1GB test is 10 times that of the 100MB test. This therefore suggests that if the 100MB concurrent test took 11.3s, the 1GB one would be estimated around 113s, and the actual value was 94s. This therefore demonstrates the efficacy of the SecureRS system. A similar deduction can be made when looking at the speed of data ingestion for the concurrent tests factoring in the network limitations.
A test was conducted utilizing a larger PDE of 10 GB and the overall time taken was 2m 24s. The average CPU was 12%, with the total amount of data stored being 13.3 GB.
Although this system was developed with small artifacts in mind, it can cater for file sizes as large as the system's memory, due to the limitations of the Fernet encryption python library. This limitation can easily be addressed by filestreaming the information instead; however, this falls outside of the scope of DFR and the research at hand. The next section VOLUME 10, 2022 discusses what the proposed model achieved and how this can aid the forensic investigation lifecycle.

VI. DISCUSSION AND CASE SCENARIO
In traditional digital forensic processes, investigators are often expected to follow the correct procedure and protocol. However, human error can occur. For example, several litigation proceedings have resulted in exculpatory outcomes due to digital evidence mishandling [46], [47]. However, automating and providing a storage engine with forensics and security in place, significantly aids an investigator. For instance, the investigator does not need to be concerned about safely securing artefacts or data that contains sensitive information. Furthermore, the threat of privacy concerns and integrity violation, which has been associated with poor digital evidence handling, can be reduced when human elements are restricted. Therefore, the forensic storage process developed in this study can be defined as the potential steps towards addressing these challenges. This system works well for digital forensic readiness whereby potential digital evidence is collected on the fly.
A case scenario of the use of the SecureRS model is to be a plugin into a collection model. For example, the previous work by the authors involved the collection of forensic artefacts from a ransomware attack using digital forensic readiness [48]. Such previous work involved collecting small-sized PDE files and storing them for further investigation. While the collection on its own is a major contribution, the authors did not ensure the extra measures to protect the PDE and ensure that it was forensically sound and admissible in a court of law. The SecureRS model solves this problem and helps other research within DFR to the extent that developed frameworks or systems do not need to be concerned about the storage and preservation of the potential digital evidence collected. However, integrating this peculiar notion of secure storage for digital investigation was quoted as potential future research. SecureRS can aid in ensuring the integrity of the collected PDE. Furthermore, the model developed in [43] asserts that the use of security standards like encryption and hashing can be used to achieve confidentiality and integrity.
Based on the performance evaluation, the model developed in [43] has a low impact on a system whilst providing a core and essential service. Extending this previous study, SecureRS provides a feasibility and proof-of-concept implementation of automated evidence storage. By integrating a reliable forensic process and practice, SecureRS provides a platform for developing a limited human interaction with potential digital evidence.

VII. SECURITY ANALYSIS
To further evaluate the developed SecureRS tool and model, a threat modelling and security analysis process was followed (see Table 14). In this model, several security features were used to protect and maintain the integrity and forensic soundness of the data stored. This was achieved by using the CIA triad and several security requirements. For instance, threats due to filename change or deletion was addressed in Secur-eRS using randomization of file name, and permission-based access control such that only permitted action (by the authorized entity) is allowed. Furthermore, the log of such an action is provided for each instance. This further addressed the need for accountability (system audit process) within the system. The SecureRS thus provide a forensic platform that can mitigate such a threat. Similarly, to ensure confidentiality and prevent the potential of sensitive information leakage, SecureRS leverages an encryption algorithm with stronger immunity.

VIII. FUTURE WORK
Future work will consider extending the platform to provide lossless compression [49] and storage optimization, developing novel methods for data ingestion, and well as develop novel methods for PDE relevance categorization. Also, potential approaches towards cloud-based evidence storage in a readiness manner will be further considered as well as extending to other sub-domains of digital forensics. As asserted in recent studies within the forensic community [50], [51], the development of a generic platform of SecureRS can be a potential solution to the lack of standardized evidence representation, as well as unified metrics towards evidence reliability evaluation/testing.

IX. CONCLUSION
In conclusion, this paper developed a model and a platform to secure Potential Digital Evidence (PDE) and to ensure the forensic soundness of the stored PDE. The platform was evaluated and shown to render good performance, despite having to go through all the forensic processes defined by the proposed model (SecureRS). Having a process in place to secure evidence can help prevent unauthorized access and comply with regulations and privacy policies, due to the nature of the data being stored. Having this model in place also helps to verify and validate the stored PDE and make it admissible in a court of law. By leveraging encryption and hashing, the SecureRS model makes good use of current security standards and therefore will aid forensic investigation in general.
The model also helps to detect evidence tampering. This paper suggests a method of ensuring forensically sound digital evidence for DFR as well as for digital forensics processes in general. So far, this aspect of forensics investigation has been widely overlooked and it was often considered to be the sole responsibility of the forensic investigator. The focus and scope of this study involved smaller artefacts for performance evaluation. With SecureRS an investigator does not need to be concerned about verification and authenticity of evidence when performing a digital investigation. The SecureRS platform furthermore acts as a backup of evidence that is securely and safely stored.