Industry Practices and Event Logging: Assessment of a Critical Software Development Process

Pecchia, Antonio; Cinque, Marcello; Carrozza, Gabriella; Cotroneo, Domenico

doi:10.1109/icse.2015.145

Cited by 70 publications

(49 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Recent work in application logging [25], [65], [64], [21], [49] has shown the efficacy of application logs in program understanding, debugging, and profiling. OmegaLog takes inspiration from those efforts, with the goal of better leveraging event logs during attack investigation.…”

Section: Our Approachmentioning

confidence: 99%

“…1(d); however, the forensic evidence disclosed by the application itself is not encoded in this graph. That is unfortunate, as recent studies [25], [21], [49] have shown that developers explicitly disclose the occurrence of important events through application logging. Further, we observe that the well-studied problem of dependency explosion [39], [42], [41], which considers the difficulty of tracing dependencies through high-fanout processes, is itself a result of unknown application semantics.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

OmegaLog: High-Fidelity Attack Investigation via Transparent Multi-layer Log Analysis

Hassan¹,

Noureddine²,

Datta³

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Recent advances in causality analysis have enabled investigators to trace multi-stage attacks using provenance graphs. Based on system-layer audit logs (e.g., syscalls), these approaches omit vital sources of application context (e.g., email addresses, HTTP response codes) that can be found in higher layers of the system. Although such information is often essential to understanding attack behaviors, it is difficult to incorporate this evidence into causal analysis engines because of the semantic gap that exists between system layers. To address that shortcoming, we propose the notion of universal provenance, which encodes all forensically relevant causal dependencies regardless of their layer of origin. To transparently realize that vision on commodity systems, we present OmegaLog, a provenance tracker that bridges the semantic gap between system and application logging contexts. OmegaLog analyzes program binaries to identify and model application-layer logging behaviors, enabling accurate reconciliation of application events with system-layer accesses. OmegaLog then intercepts applications' runtime logging activities and grafts those events onto the system-layer provenance graph, allowing investigators to reason more precisely about the nature of attacks. We demonstrate that our system is widely applicable to existing software projects and can transparently facilitate execution partitioning of provenance graphs without any training or developer intervention. Evaluation on real-world attack scenarios shows that our technique generates concise provenance graphs with rich semantic information relative to the state-of-the-art, with an average runtime overhead of 4%.

show abstract

Section: Our Approachmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

OmegaLog: High-Fidelity Attack Investigation via Transparent Multi-layer Log Analysis

Hassan¹,

Noureddine²,

Datta³

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Similarly, the work by [23] uses a term weighting measurement approach to find faults from syslog. The study [24] adopts a term weighting approach to assess a variety of direct monitoring approaches, such as event logs [25], [26], at reporting the occurrence of operational failures in critical systems. This is the first contribution that investigates the use of term weighting to address security logs: the mentioned works focus on reliability rather than security analysis.…”

Section: Data Sourcesmentioning

confidence: 99%

Automated root cause identification of security alerts: Evaluation in a SaaS Cloud

Cotroneo

Paudice²,

Pecchia

2016

Future Generation Computer Systems

Self Cite

View full text Add to dashboard Cite

“…Even though developers have been analyzing logs for decades [31], there exists no industrial standard on how to write logging statements [20,49]. Prior studies often focus on recommending where logging statements should be added into the code (i.e., where-to-log) [76,75], and what information should be added in logging statements (i.e., what-to-log) [59,73,51].…”

Section: Introductionmentioning

confidence: 99%

Characterizing and Detecting Duplicate Logging Code Smells

2019

2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)

View full text Add to dashboard Cite

School of Graduate StudiesThis is to certify that the thesis prepared By: Zhenhao Li Entitled: Characterizing and Detecting Duplicate Logging Code Smells and submitted in partial fulfillment of the requirements for the degree of Master of Applied Science (Software Engineering) complies with the regulations of this University and meets the accepted standards with respect to originality and quality. Abstract Characterizing and Detecting Duplicate Logging Code Smells Zhenhao Li Developers rely on software logs for a wide variety of tasks, such as debugging, testing, program comprehension, verification, and performance analysis. Despite the importance of logs, prior studies show that there is no industrial standard on how to write logging statements. Recent research on logs often only considers the appropriateness of a log as an individual item (e.g., one single logging statement); while logs are typically analyzed in tandem. In this thesis, we focus on studying duplicate logging statements, which are logging statements that have the same static text message. Such duplications in the text message are potential indications of logging code smells, which may affect developers' understanding of the dynamic view of the system. We manually studied over 3K duplicate logging statements and their surrounding code in four large-scale open source systems:Hadoop, CloudStack, ElasticSearch, and Cassandra. We uncovered five patterns of duplicate logging code smells. For each instance of the code smell, we further manually identify the problematic (i.e., require fixes) and justifiable (i.e., do not require fixes) cases. Then, we contact developers in order to verify our manual study result. We integrated our manual study result and developers' feedback into our automated static analysis tool, DLFinder, which automatically detects problematic duplicate logging code smells. We evaluated DLFinder on the four manually studied systems and four additional systems: Kafka, Flink, Camel and Wicket. In total, combining the results of DLFinder and our manual analysis, we reported 91 problematic code smell instances to developers and all of them have been fixed. This thesis provides an initial step on creating a logging guideline for developers to improve the quality of logging code. DLFinder is also able to detect duplicate logging code smells with high precision and recall.iii

show abstract

Industry Practices and Event Logging: Assessment of a Critical Software Development Process

Cited by 70 publications

References 18 publications

OmegaLog: High-Fidelity Attack Investigation via Transparent Multi-layer Log Analysis

OmegaLog: High-Fidelity Attack Investigation via Transparent Multi-layer Log Analysis

Automated root cause identification of security alerts: Evaluation in a SaaS Cloud

Characterizing and Detecting Duplicate Logging Code Smells

Contact Info

Product

Resources

About