Security incidents can arise from the misuse of existing software systems. Thus, appropriate logging mechanisms should be implemented at the software level to support the detection and investigation of security incidents. However, due to insufficient logging, security incidents often go undetected for long periods. Moreover, even after a security incident is detected, there is not enough information to fully reconstruct how an incident occurred. Insufficient logging may be due to the limited security expertise of software developers, who may not know what are the most critical security incidents. Also, for large software systems and a multitude of potential misuse scenarios, it is cumbersome to identify when and what logging instructions should be implemented. In this paper, we propose a preliminary idea to automate the development of "forensic-ready" software systems. These systems can log a minimum amount of relevant data that can be used to detect and investigate potential security incidents. Our approach allows a security engineer to elicit a set of potential software misuse scenarios, expressed as annotated sequence diagrams. These diagrams are then used-together with a control flow graph of the software system-to identify the exact location where logging instructions should be placed and the information they should log. Finally, logging instructions can be injected into designated software system locations using Aspect-Oriented Programming. We illustrate our approach using an example of software misuse in a human resources management software system.

In 2017 the Open Web Application Security Project (OWASP) has identified insufficient logging and monitoring as one of the top ten security risks. Attackers can exploit insufficient logging in software systems to cause harm to an organisation while being undetected for long periods of time. Therefore, software systems used within an organisation should perform logging to collect data relevant to detect and/or diagnose potential security incidents. However, when implementing logging functionalities, software developers either do not log enough information or log too much information. In this paper, we provide an approach to help developers decide where to log and what to log for security purposes. Our approach allows a security engineer to replay potential security incidents on an instrumented version of the software system and generate automatically a model of such incidents. These are represented as a UML sequence diagram that contains the relevant method invocations occurring during and incident, without providing a representation of the entire software behaviour. Because our model refers to concrete system components, it provides immediate guidance to developers about what methods execution should be logged for security purposes.