A forensic-ready software system can produce logs that represent potential evidence in digital forensic investigations of potential security incidents. Logs can reveal the identity of ofenders, what happened during an incident and when and how the incident was performed. However, it is hard for developers to implement security logging, especially in large software systems, because it requires identifying only the relevant and necessary information to be logged to support a digital forensics investigation. Moreover, developers might not have the security expertise to think in advance about potential security incidents that can occur. Existing approaches in the software engineering community have mainly supported logging to diagnose and fix either run-time or performance errors, without considering security logging. Other research approaches have focused on engineering forensic-ready software systems, without supporting the automated generation of security logs. The purpose of this PhD research is to assist software developers to build forensic-ready software systems, which can implement logging functionality to support digital investigations of potential security incidents. We propose a semi-automated approach called Forensic-Ready Logger ( FRL ). Our approach help developers to elicit a set of potential software misuse scenarios, expressed as annotated UML Sequence Diagrams. Such diagrams are subsequently used to identify the exact location where logging instructions should be placed and the information they should log. Finally, The Forensic-Ready Logger approach automatically injects logging instructions within the software system. We want to evaluate first the conclusion validity and the performance of the Forensic-Ready Logger approach using a Computational Study where we will use a human resource management application built from scratch and a third-party open-source software system. Second, We will also assess the efectiveness of the Forensic-Ready Logger approach by using a Judgement study where we will seek software practitioners to provide feedback on its usefulness and usability.
A forensic-ready software system can produce logs that represent potential evidence in digital
forensic investigations of potential security incidents. Logs can reveal the identity of ofenders,
what happened during an incident, and when and how the incident was performed [
The purpose of this research is to help software developers to build forensic-ready software
systems, which can implement logging functionality to support digital forensics
investigations. Hence, developers need to decide where to log, which are the locations where logging
statements should be placed, and what to log, which is the information to be recorded in the
logs [
This research abstract is organised as follows. Section 2 presents previous research related to Logging in the Software Engineering community. Section 3 addresses the research questions that our work considers and describes the Forensic-Ready Logger approach. Section 4 discusses the methodology and the evaluation we use, and Section 5 concludes.
In the Literature review, we found that Logging has categories such as Information Systems (Workflows), Databases, and Software Engineering. Our research focused on Logging into Software Systems for Security purposes. Hence, our research does not consider the other two categories.
Previous software engineering research has focused on understanding how developers
implement logging in software systems. For example, Chen and Ming [
Researchers in the software engineering community have proposed approaches to guide
security logging. For example, William and King [
Finally, another line of work has tried to incorporate satisfaction of forensic readiness requirements [12] in the software development life-cycle. These requirements refer to the capability of software to collect and produce forensically sound evidence that is tamper-proof and admissible in court. Daubner et al. [13] propose high-level and unproved guidelines to verify whether a software system generates potential evidence and, thus, can be considered forensic-ready. Yu et al. [14] provides an approach to collect evidence related to drone incidents that is forensically sound and that could demonstrate whether the drone violated any regulations. Although this research supports evidence collection to facilitate drone incidents investigations, such evidence is only collected from physical sensors recording drone flight data. Alrajeh et al. [ 15] propose an approach to represent evidence preservation requirements considering the preservation of the minimal amount of data that would be relevant to a future digital investigation. This approach automatically generates a software specification indicating how to store minimal and relevant to investigate a security incident. However, it does not automate the implementation of logging statements within software systems.
Therefore, more efort is required to propose the usage of logs for security inside Software
Systems[11] to provide information for forensic analysis to help answer who, what, when,
where, and how a security incident happened[
The purpose of this research is to help software developers to build forensic-ready software systems, which can implement logging functionality to support digital forensics investigations. To achieve this aim, we answer the following research questions: 1. RQ1: How can we elicit security logging requirements that can be traced to software components and method invocations? 2. RQ2: How can we generate automatically logging instructions that comply with forensicready software systems requirements, such as relevance and minimality?
To answer RQ1 we provide an approach to generate automatically a model of a security incident by emulating the misuse of a software system. This model is represented as a sequence diagram, where message exchanges have a direct mapping to method invocations. We also allow annotating this model by specifying conditions that determine whether an incident is occurring. To answer RQ2, we use the information provided in the incident model to identify where logging should be implemented and which information should be logged. Finally, we propose an approach to instrument the software system to inject the logging statements at specific points of the software system implementation.
We propose a semi-automated approach named Forensic-Ready Logger( FRL ) [
The kind of software misuses that our FRL approach considers are based on the STRIDE[16] model. This is a model of threats that validates the application design. Some examples of threats are spoofing identity, tampering with data, repudiation, information disclosure, the elevation of privilege. Such software misuses are relevant to discover in a software system because they provide accountability of bad behaviour conducted by personnel in the organisation (e.g., Software Administrators, Managers, employees) or former employees that might have permissions to software systems and could seek revenge against the organisation[17].
The Forensic-Ready Logger approach provides the following main functionalities: 2A Java-based implementation of the system is available publicly at https://github.com/friveraortiz/Projects.git annotation type ( i.e., Method, Parameter or Return Value ).
Jørgen Bøegh[25] presents the ISO/IEC 9126 software quality model used by developers and researchers, which describes the quality requirements for software (e.g., Functionality, Reliability, Usability, Eficiency, Maintainability, Portability)[ 25]. Our research considers the Eficiency and Usability quality requirements.
Our FRL approach can have two usages scenarios that can show the trade-ofs between enabling the capability of detecting security incidents in the software systems and these quality requirements. The first scenario is, the Security Engineer selects manually the relevant methods and necessary conditions to log to diagnose the security incident. Such a scenario impacts Usability because there is required manual input from the Security Engineer. It also afects eficiency in a positive way because the FRL approach will have a shortlist of methods and will perform in less time. The second scenario is, all the methods are logged without any human intervention. This scenario causes Usability that no manual input is required and it saves time for the Security Engineer. About eficiency, it causes more overhead because more methods will be included and it will require more time to perform our FRL approach.
Our Forensic-Ready Logger(FRL) approach is novel for two reasons. First, it generates a UML
Sequence Diagram automatically that presents the Incident Model, which includes the methods
invoked when the misuse scenario is replayed in the software system. We decided to use
such a Sequence diagram because we considered the work of Briand et al.[26], who suggested
reverse-engineering a Java Application by instrumenting the application using AspectJ[21].
However, such a diagram included the entire software system behavior and all components inside
the system. Labiche et al.[27] improved this approach by representing in the UML Sequence
Diagram the necessary components such as caller and callee objects, method signature, class
name, and line number of the call. We considered the work from Labiche et al.[27] and we
included in the UML Sequence Diagram the essential information about Java methods (e.g.,
caller, callee objects, method signature, class name)[11]. However, even with this consideration,
a software system can have a multitude of methods. Generating a UML sequence diagram that
includes all the method invocations that occurred during a security incident, might result in
an extremely extensive UML sequence diagram which can be extremely dificult for a security
engineer to understand the locations and the places to detect the security incident. To reduce
dramatically the number of methods included in the UML sequence diagram, we include only
the methods invoked when the misuse scenario is replayed in the software system. Furthermore,
these methods perform data access or changes in the database[
Second, our FRL approach provides a practical way to transform a software system into a forensic-ready software system by generating and injecting logging instructions in the system implementation. The logs generated by the Forensic-Ready Logger approach provide potential evidence to demonstrate how a security incident related to software misuse took place [11].
To evaluate our Forensic-Ready Logger approach, we are using a mixed-method. First, we evaluate the technical part of the Forensic-Ready Logger ( FRL ) approach. We will assess the conclusion validity[28] of the FRL approach by verifying whether it can log data that is relevant[12] to an incident and avoid collecting unnecessary data (minimality[12]). To assess relevance will evaluate if the Forensic-Ready Logger ( FRL ) approach creates automatically a UML Sequence Diagram that contains the actors, packages, classes, and methods that are called when a Security Incident occurs in the software system. We will assess whether the Forensic-Ready Logger ( FRL ) approach includes logging instructions that generate a log that contains information to detect when and how a security incident of interest occurs. We will also evaluate the performance of the Forensic-Ready Logger ( FRL ) approach to generate an incident model and the logging instruction. To assess the external validity[28], we will conduct a computational study[29] using Java Systems, a Human Resource Management System implemented from scratch3 and a large scale open-source system available publicly, such as OpenHospital4. Once we have finished evaluating the technical part, we will seek the participation of Software Engineers to assess the efectiveness of the Forensic-Ready Logger ( FRL ) approach by performing a judgement study[29] where we will ask them to use the Forensic-Ready Logger approach to provide feedback on its usefulness and usability[25]. The elements that the software engineers will evaluate in our FRL approach are, First, the practicality of our approach to generating the misuse scenarios in the Incident Model, they will assess how useful it is such model to detect the security incident that could happen in the Software System. Second, is the practice of annotating the Incident Model, where they will assess the common mistakes that happen while annotating such Model. Third, the format of the generated logs that diagnose security incidents, where developers will evaluate if such format is understandable to detect security incidents inside the software system.
To detect security incidents, software systems need to be prepared in advance. Hence, this research presents how to transform software systems into forensic-ready software systems. Such systems can generate logs that detect and diagnose potential security incidents. Furthermore, this research contributes with a practical tool for software developers to implement security incidents in Software Systems. To the best of our knowledge, this is one of the first approaches to propose the automated generation of logging instructions that can cover relevant security incidents [11]. We have completed the development of the Forensic-Ready Logger( FRL ) approach. Our next step is to create more attack scenarios that could happen in the Human Resource Management Software System (HRM) and test them using our FRL approach. After that, we will evaluate our Forensic-Ready Logger approach in a more complex Java Software System using several attack scenarios, and finally, we will conduct a Case Study where we will seek the participation of software developers to evaluate the practicality and usefulness of our 3A Java-based implementation of the system is available publicly at https://github.com/friveraortiz/Projects.git 4A Java-based open-source system https://github.com/informatici/openhospital Forensic-Ready Logger approach.
This work was partially supported by Science Foundation Ireland grants 13/RC/2094_P2 and 15/SIRG/3501. [11] F. Rivera-Ortiz, L. Pasquale, Towards automated logging for forensic-ready software systems, in: Proceedings of the 6th International Workshop on Evolving Secuirty and Privacy Requirements Engineering (ESPRE’19), IEEE, Jeju Island, South Korea, 2019, pp. 1–7. [12] L. Pasquale, D. Alrajeh, C. Peersman, T. Tun, B. Nuseibeh, A. Rashid, Towards forensicready software systems, in: In Proceedings of the 40th International Conference on Software Engineering (ICSE’18), ACM, Gothenburg, Sweden, 2018, pp. 1–4. [13] L. Daubner, M. Macak, B. Buhnova, T. Pitner, Towards verifiable evidence generation in forensic-ready systems, in: Proceedings of the 2020 International Conference on Big Data (Big Data’20), IEEE, Virtual Event, USA, 2020, pp. 2264–2269. [14] Y. Yu, D. Barthaud, B. A. Price, A. K. Bandara, A. Zisman, B. Nuseibeh, Livebox: A self-adaptive forensic-ready service for drones, IEEE Access 7 (2019) 148401–148412. [15] D. Alrajeh, L. Pasquale, B. Nuseibeh, On evidence preservation requirements for forensicready systems, in: Proceeding of 11th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE’17), ACM, Paderborn, Germany, 2017, pp. 559–569. [16] A. Hewko, Stride threat modelling: What you need to know, 2022. URL: https://www.
softwaresecured.com/stride-threat-modeling/. [17] FBI, Medical equipment packaging company hacker sentenced, 2021. URL: https://www.
fbi.gov/news/stories/hacker-who-disrupted-ppe-shipments-sentenced-010621. [18] G. McGraw, Software security, IEEE Security & Privacy 2 (2004) 80–83. [19] B. Arkin, S. Stender, G. McGraw, Software penetration testing, IEEE Security & Privacy 3 (2005) 84–87. [20] N. C. S. Centre, Penetration testing, 2017. URL: https://www.ncsc.gov.uk/guidance/ penetration-testing. [21] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, J. Irwin, Aspect-oriented programming, in: Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP’97), ACM, Jyväskylä, Finland, 1997, pp. 1–25. [22] OWASP, Owasp top 10-2021, 2021. URL: https://owasp.org/Top10/ #welcome-to-the-owasp-top-10-2021. [23] J. King, R. Pandita, L. Williams, Enabling forensics by proposing heuristics to identify mandatory log events, in: Proceedings of the 2015 Symposium and Bootcamp on the Science of Security (HotSoS’15), ACM, Urbana, Illinois, USA, 2015, pp. 1–10. [24] A. Chuvakin, G. Petterson, How to do application logging right, IEEE Security and Privacy 8 (2010) 82–85. [25] J. Bøegh (????). [26] L. C. Briand, Y. Labiche, J. Leduc, Toward the reverse engineering of uml sequence diagrams for distributed java software, IEEE Transactions on Software Engineering 32 (2006) 642–663. [27] Y. Labiche, B. Kolbah, H. Mehrfard, Combining static and dynamic analyses to reverseengineer scenario diagrams, in: 2013 IEEE International Conference on Software Maintenance, IEEE, 2013, pp. 130–139. [28] R. Feldt, A. Magazinius, Validity threats in empirical software engineering research an initial survey, in: Proceedings of the 22nd International Conference on Software Engineering and Knowledge Engineering (SEKE’10), ACM, Redwood City, San Francisco Bay, USA, 2010, pp. 1–6. [29] C. Williams, M.-A. Storey, N. A. Ernst, A. Zagalsky, E. Kalliamvakou, Methodology matters: How we study socio-technical aspects in software engineering, ACM Transactions on Software Engineering and Methodology 37 (2019) 1–22.